Acabamos de migrar nuestra instancia de Discourse autoalojada de un servidor a otro. Todos los ajustes se migraron del sistema antiguo al nuevo, incluyendo «responder por correo electrónico» y «permitir nuevos mensajes a través del correo electrónico». Estamos utilizando la configuración de discourse/mail-receiver para gestionar la parte del correo.
Tanto la funcionalidad de «responder a» como la de «nuevo correo» funcionaron perfectamente en el sistema antiguo, pero tenemos un problema en el nuevo servidor: «responder a» ya no funciona.
Como usuario desconocido, cuando envío un correo electrónico a la dirección configurada para este fin, veo que el mensaje llega. Se crea un nuevo usuario en fase de preparación. ¡El mensaje se publica! Genial.
Como usuario del equipo, puedo responder a este mensaje y se entrega correctamente. ¡Excelente!
PERO, al volver a responder a ese correo, lo que debería generar una respuesta en Discourse, falla. Cuando el mensaje llega a mail-receiver, intenta entregarlo a través de la API, pero falla con los siguientes errores en el registro:
(Por razones de privacidad, he modificado los nombres de usuario y dominio)
Como mencioné, todo este intercambio funcionó perfectamente en la configuración antigua. La nueva configuración es exactamente la misma (local_discourse/app y local_discourse/mail-receiver) que la antigua.
¿Podría alguien decirme por qué la API handle_mail devuelve un error 400 al recibir un correo de respuesta?
¿Sería posible hacer que el registro sea más detallado para poder investigar más a fondo?
Me pregunto cuál es la diferencia entre el ‘correo nuevo’ y el ‘correo de respuesta’. Diría que la única diferencia relevante es el destinatario. Pero ambos pasan por el mismo manejador (mail-receiver) y se publican en la misma API: https://forum.acme.org/admin/email/handle_mail
El problema no está en la parte de MX. El correo sí llega al receptor de correo, como muestran los registros, pero tan pronto como se envía al API, recibe un error 400 (lo que significa una solicitud incorrecta).
Sin embargo, hay una diferencia en la configuración: he colocado un proxy inverso (nginx) delante para obtener la funcionalidad de “fuera de línea temporal” y, posiblemente, alojar otros sitios web en el mismo servidor. Aún no entiendo por qué sería un problema, ya que se está aceptando un nuevo tema sin ningún contratiempo. Aun así, voy a ver qué sucede si saco el proxy inverso de la ecuación…
Actualización
¡Qué lástima! Movi la instalación de Discourse detrás del proxy inverso de nginx (básicamente reconstruyendo app con la configuración correcta y apagando nginx), ¡pero esto no solucionó el problema en absoluto!
Ahora, realmente no tengo idea. ¿Qué está pasando aquí?
Para resumir:
Nuestra instalación anterior de Discourse (app y mail-receiver) podía aceptar nuevos temas y respuestas.
Después de migrar a un nuevo servidor (todo exactamente igual), los nuevos temas siguen siendo aceptados, pero las respuestas están siendo rechazadas con un error 400 Bad Request.
He encontrado el problema que está causando esta situación.
Al probar con varios clientes de correo, descubrí que los correos enviados con mi cliente de escritorio (Thunderbird) generaban el error ‘400 Bad Request’, mientras que al usar el cliente web, la respuesta se enviaba correctamente.
Tras investigar más a fondo, descubrí que Thunderbird de alguna manera cambiaba a codificación Western (Windows-1252) al responder, mientras que el cliente web se mantenía en UTF-8. Tras forzar a Thunderbird a usar UTF-8, el correo también se envió correctamente.
Diría que el receptor del correo debería realizar una verificación y limpieza de la codificación, pero como no soy desarrollador de Ruby, dejo esa parte del código en manos de los desarrolladores
