« Répondre par e-mail » ne fonctionne plus après la migration

Soutien
1

Bonjour,

Nous venons de migrer notre instance Discourse auto-hébergée d’un serveur vers un autre. Tous les paramètres ont été transférés de l’ancien au nouveau système, y compris « répondre par e-mail » et « autoriser les nouveaux messages par e-mail ». Nous utilisons la configuration discourse/mail-receiver pour gérer la partie e-mail.
La fonctionnalité de réponse (reply-to) et celle des nouveaux e-mails ont parfaitement fonctionné sur l’ancien système, mais nous rencontrons un problème sur le nouveau serveur : la réponse par e-mail ne fonctionne plus.

  1. En tant qu’utilisateur inconnu, lorsque j’envoie un e-mail à l’adresse configurée à cet effet, je vois le message arriver. Un nouvel utilisateur temporaire est créé. Le message est publié. Super !
  2. En tant qu’utilisateur de l’équipe, je peux répondre à ce message, et le message est bien délivré. Excellent !
  3. MAIS une nouvelle réponse à cet e-mail, qui devrait générer une réponse dans Discourse, échoue. Lorsque le message arrive dans mail-receiver, il tente de le transmettre via l’API, mais cela échoue avec les erreurs de journal suivantes.

(Pour des raisons de confidentialité, j’ai modifié les noms d’utilisateurs et de domaine)

<22>Sep 13 09:45:15 postfix/qmgr[81]: AF8665CA560: from=<test-user@outside-org.nl>, size=9233, nrcpt=1 (queue active)
<23>Sep 13 09:45:15 receive-mail[144]: Recipient: 6ffb2772c3b09bf60fc2705753fb32ce@forum.acme.org
<19>Sep 13 09:45:15 receive-mail[144]: Failed to POST the e-mail to https://forum.acme.org/admin/email/handle_mail: 400
<22>Sep 13 09:45:15 postfix/pipe[143]: AF8665CA560: to=<6ffb2772c3b09bf60fc2705753fb32ce@forum.acme.org>, relay=discourse, delay=1126, delays=1126/0.01/0/0.21, dsn=4.3.0, status=deferred (temporary failure)

Comme je l’ai dit, tout ce va-et-vient fonctionnait parfaitement dans l’ancienne configuration. La nouvelle configuration est exactement la même (local_discourse/app et local_discourse/mail-receiver) que l’ancienne.

  • Quelqu’un pourrait-il m’expliquer pourquoi l’API handle_mail renvoie une erreur 400 pour un e-mail de réponse ?
  • Serait-il possible de rendre la journalisation plus détaillée afin que je puisse approfondir l’analyse ?
2

Vous devriez pouvoir trouver plus d’informations dans Admin - E-mails - Rejetés.

3

Non, désolé, cela n’apparaît même pas comme Rejeté. Je suppose que c’est parce que cela se heurte à une erreur 400 Bad Request…

4

Je me demande quelle est la différence entre le « nouveau message » et le « message de réponse ». Je dirais que la seule différence pertinente est le destinataire. Mais les deux passent par le même gestionnaire (mail-receiver) et sont envoyés vers la même API : https://forum.acme.org/admin/email/handle_mail

5

L’avez-vous migré également ? Avez-vous mis à jour les enregistrements MX en conséquence ?

Avez-vous modifié le nom d’hôte de votre forum ?

6
  • Le récepteur de courriel a également été migré.
  • Les noms d’hôte restent identiques.

Le problème ne se situe pas au niveau de la partie MX. Le courriel arrive bien au récepteur de courriel, comme le montrent les journaux, mais dès qu’il soumet le message à l’API, il reçoit une erreur 400 (ce qui signifie une requête incorrecte).

7

Il y a cependant une différence dans la configuration : j’ai placé un proxy inverse (nginx) devant pour obtenir la fonctionnalité « hors ligne temporaire » et éventuellement héberger d’autres sites sur le même hôte. Je ne comprends toujours pas pourquoi cela poserait problème, car un nouveau sujet est accepté sans aucun accroc. Cependant, je vais voir ce qui se passe si j’élimine le proxy inverse de l’équation…

Mise à jour
Trop dommage ! J’ai déplacé l’installation de Discourse derrière le proxy inverse nginx (en reconstruisant essentiellement app avec les paramètres corrects et en arrêtant nginx), mais cela n’a absolument rien résolu !
Maintenant, je suis vraiment à court d’idées. Qu’est-ce qui se passe ici ?

Pour résumer :

  • Notre précédente installation de Discourse (app et mail-receiver) acceptait les nouveaux sujets et réponses
  • Après la migration vers un nouveau serveur (tout identique), les nouveaux sujets sont toujours acceptés, mais les réponses sont rejetées avec une erreur 400 Bad Request.
8

J’ai identifié le problème à l’origine de cette situation.
En testant plusieurs clients de messagerie, j’ai constaté que les courriels envoyés avec mon client de bureau (Thunderbird) rencontraient l’erreur « 400 Bad Request », tandis que, lors de l’utilisation du client web, la réponse arrivait normalement.
Après investigation plus poussée, j’ai découvert que Thunderbird basculait d’une manière ou d’une autre vers un encodage Western (Windows-1252) lors de la réponse, alors que le client web restait sur l’UTF-8. Après avoir forcé Thunderbird à utiliser l’UTF-8, le courriel a également été transmis.

Thunderbird, le courriel n’a pas été transmis

Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Courriel web

Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

Thunderbird, le courriel a été transmis

Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Je dirais que le récepteur de courriels devrait effectuer une vérification et un nettoyage de l’encodage, mais comme je ne suis pas développeur Ruby, je laisse cette partie du code entre les mains des développeurs :smiley: