abbiamo appena migrato la nostra istanza di Discourse auto-ospitata da un server a un altro. Tutte le impostazioni sono state migrate dal vecchio al nuovo sistema, inclusi ‘rispondi via email’ e ‘consenti nuovi post tramite email’. Stiamo utilizzando la configurazione discourse/mail-receiver per gestire la parte relativa alle email.
Sia la funzionalità di risposta che quella di nuova email funzionavano perfettamente nel vecchio sistema, ma sul nuovo server abbiamo un problema: la risposta non funziona più.
Come utente sconosciuto, quando invio un’email all’indirizzo configurato a questo scopo, vedo l’arrivo della mail. Viene creato un nuovo utente in fase di staging. Il messaggio viene pubblicato. Fantastico!
Come utente del team, posso rispondere a questo messaggio e il messaggio viene recapitato correttamente. Ottimo!
MA riprovando a rispondere a quell’email, che dovrebbe generare una risposta in Discourse, l’operazione fallisce. Quando il messaggio arriva in mail-receiver, tenta di recapitarlo tramite l’API, ma fallisce con i seguenti errori di log.
(Per motivi di privacy, ho modificato i nomi degli utenti e dei domini)
Come ho detto, questo scambio completo funzionava perfettamente nella vecchia configurazione. La nuova configurazione è esattamente la stessa (local_discourse/app e local_discourse/mail-receiver) della vecchia.
Qualcuno potrebbe spiegarmi perché l’API handle_mail restituisce un errore 400 su un’email di risposta?
Sarebbe possibile rendere il logging più dettagliato, così da poter approfondire l’analisi?
Mi chiedo qual è la differenza tra ‘nuova email’ e ‘email di risposta’. Direi che l’unica differenza rilevante è il destinatario. Ma entrambe passano attraverso lo stesso gestore (mail-receiver) e vengono inviate alla stessa API: https://forum.acme.org/admin/email/handle_mail
Il problema non risiede nella parte MX. La posta arriva effettivamente al ricevitore di posta, come mostrano i log, ma non appena viene inviata all’API, si riceve un errore 400 (che indica una richiesta errata).
C’è una differenza, però, nella configurazione: ho messo un reverse proxy (nginx) davanti per ottenere la funzionalità ‘temporaneamente offline’ e, possibilmente, ospitare altri siti sullo stesso host. Non capisco ancora perché dovrebbe essere un problema, dato che un nuovo argomento viene accettato senza intoppi. Tuttavia, vedrò cosa succede se rimuovo il reverse proxy dall’equazione…
Aggiornamento
Peccato! Ho spostato l’installazione di Discourse dietro il reverse proxy nginx (ricostruendo fondamentalmente app con le impostazioni corrette e spegnendo nginx), ma questo non ha affatto risolto il problema!
Ora sono davvero nel caos. Cosa sta succedendo qui?
Per riassumere:
La nostra precedente installazione di Discourse (app e mail-receiver) poteva accettare nuovi argomenti e risposte
Dopo la migrazione a un nuovo server (tutto identico), i nuovi argomenti vengono ancora accettati, ma le risposte vengono respinte con un errore 400 Bad Request.
Ho individuato il problema che causa questa situazione.
Mentre provavo diversi client di posta, ho scoperto che le email inviate con il mio client desktop (Thunderbird) ricevevano l’errore ‘400 Bad Request’, mentre usando il client web la risposta arrivava regolarmente.
Dopo un’ulteriore indagine, ho scoperto che Thunderbird in qualche modo passava automaticamente alla codifica Western (Windows-1252) durante le risposte, mentre il client web rimaneva su UTF-8. Dopo aver forzato Thunderbird a utilizzare UTF-8, anche le email sono state inviate con successo.
Direi che il ricevitore delle email dovrebbe effettuare controlli e pulizie sulla codifica, ma non sono uno sviluppatore Ruby, quindi lascio questa parte del codice agli sviluppatori
