Estensione del timeout SMTP

È possibile estendere l’intervallo di timeout quando Discourse attende che il server SMTP restituisca l’acknowledgment che un messaggio email è stato inviato? In alternativa, è possibile configurare Discourse per non richiedere questo acknowledgment.

Sto riscontrando un problema per cui la mia istanza di Discourse genera email duplicate. Discourse riceve un errore Net::Timeout durante l’invio di email per la consegna. Il mio provider di posta elettronica sta effettivamente consegnando le email, ma Discourse non lo sa e procede a reinviare le email. Questo si ripete all’infinito.

Recentemente abbiamo aggiunto la personalizzazione del timeout SMTP, ma si tratta di stabilire la connessione SMTP effettiva:

Sembra che il tuo problema si verifichi dopo che la connessione è stata stabilita e il problema riguarda il timeout della transazione di invio?

2 Mi Piace

Sì, per quanto ne so. La connessione viene stabilita, il messaggio e-mail viene inviato ma dopo si verifica un errore Net::Timeout.

Utilizzando lo script discourse_doctor, vedo l’ID del messaggio restituito quando la transizione ha successo e l’errore Net::Timeout quando fallisce.

Questo problema è emerso dopo l’aggiornamento a Discourse 2.9.0.beta5. Presumo che Discourse sia diventato meno permissivo nei confronti di questo errore con quell’aggiornamento.

Non ho trovato modifiche correlate nelle gemme ruby mail e net/smtp. Forse il tuo server SMTP si sta comportando in modo anomalo? Saresti in grado di migrare a un altro?

1 Mi Piace

Grazie per aver controllato. Sono d’accordo, il mio provider di posta elettronica sembra essere la causa del problema in quanto non risponde abbastanza rapidamente dopo l’invio di un’e-mail. Posso solo ipotizzare che il problema sia in qualche modo correlato al carico, nel senso che alcuni giorni non riscontro il problema.

Cambiare provider di posta elettronica è una sfida significativa per una serie di motivi. Trovare un modo per configurare Discourse per aggirare questo problema è la soluzione più attraente.

Spostare a un nuovo provider di posta sembra l’unica soluzione a questo problema, ma ciò richiede la riconfigurazione del provider di posta per il mio intero dominio, un’operazione che vorrei evitare.

C’è qualche modifica che posso apportare al codice di Discourse che gestisce l’invio di posta per fargli ignorare i fallimenti nell’invio della posta, come faceva in passato? Non sono uno sviluppatore Rails, quindi non so nemmeno da dove cominciare. Non voglio compromettere la mia capacità di accettare futuri aggiornamenti di Discourse.

Su cosa basi l’affermazione di cui sopra? Puoi ricevere posta solo su un’infrastruttura per dominio/sottodominio, ma diversi servizi possono inoltrare l’email per suo conto.

In alternativa, potresti anche creare un nuovo sottodominio dedicato alla tua istanza, che non richiede nemmeno una ricostruzione per la configurazione.

Ci ho provato in passato e ho configurato male le cose e non sono riuscito a capirlo, da qui la mia riluttanza a cambiare qualcosa. Preferirei anche che le email di Discourse provenissero dal dominio della mia azienda, ma dato che non funzionerà più, ci riproverò come suggerisci e userò un sottodominio per le email in uscita.

Ho creato un sottodominio email utilizzando RackSpace Cloud e ho confermato di poter inviare posta tramite esso dal mio Mac utilizzando Apple Mail e curl. Ho anche confermato di poter inviare posta dal mio server utilizzando curl. Tuttavia, sto ricevendo questo errore da discourse-doctor:

Testing sending to support@latenightsw.com using secure.emailsrvr.com:465, username:username with plain auth.
======================================== ERROR ========================================
                                    UNEXPECTED ERROR

Net::ReadTimeout

====================================== SOLUTION =======================================
This is not a common error. No recommended solution exists!

Please report the exact error message above to https://meta.discourse.org/
(And a solution, if you find one!)

Il mio file app.yml contiene queste impostazioni:

  DISCOURSE_SMTP_ADDRESS: secure.emailsrvr.com         # (mandatory)
  DISCOURSE_SMTP_PORT: 465                             # (optional)
  DISCOURSE_SMTP_USER_NAME: username      # (optional)
  DISCOURSE_SMTP_PASSWORD: password               # (optional, WARNING the char '#' in pw can cause problems!)

  #DISCOURSE_SMTP_ENABLE_START_TLS: true           # (optional, default true)

Ciò corrisponde alla configurazione documentata qui.

Ho provato a impostare DISCOURSE_SMTP_ENABLE_START_TLS su false. Altri post per l’errore Net::ReadTimeout suggeriscono di provare queste impostazioni, ma non hanno fatto alcuna differenza:

  DISCOURSE_SMTP_AUTHENTICATION: "login"
  DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none

Come posso diagnosticare questo errore?

@Falco come posso apportare questa modifica alla mia configurazione di Discourse? Non riesco a trovare alcuna documentazione per un’impostazione che posso aggiungere al mio file app.yml.