«Ответ по электронной почте» перестал работать после миграции

Поддержка
1

Здравствуйте,

Мы только что перенесли наш самодостаточный экземпляр Discourse с одного сервера на другой. Все настройки были перенесены со старой системы на новую, включая «ответ через электронную почту» и «разрешение новых сообщений через электронную почту». Для обработки электронной почты мы используем связку discourse/mail-receiver.

Функционал «ответить» и «создать новое сообщение по почте» отлично работал в старой системе, но на новом сервере возникла проблема: функция «ответить» больше не работает.

  1. Как неизвестный пользователь, когда я отправляю письмо на специально настроенный для этого адрес, я вижу входящее письмо. Создается новый пользователь в статусе «на рассмотрении». Сообщение публикуется. Отлично!
  2. Как пользователь команды, я могу ответить на это сообщение, и оно доставляется корректно. Супер!
  3. НО повторная отправка ответа на это письмо, которая должна привести к ответу в Discourse, не удаётся. Когда сообщение поступает в mail-receiver, он пытается передать его через API, но это завершается ошибкой, о чём свидетельствуют следующие записи в логах.

(По соображениям конфиденциальности я изменил имена пользователей и домены)

<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)

Как я уже сказал, вся эта цепочка обмена сообщениями отлично работала в старой настройке. Новая настройка полностью идентична старой (local_discourse/app и local_discourse/mail-receiver).

  • Не могли бы вы подсказать, почему API handle_mail возвращает ошибку 400 при ответе на письмо?
  • Возможно ли сделать логирование более подробным, чтобы я мог глубже разобраться в проблеме?
2

Вы должны найти дополнительную информацию в разделе Администрирование — Электронная почта — Отклонённые.

3

Нет, извините, оно даже не отображается как отклонённое. Думаю, это связано с ошибкой 400 Bad Request…

4

Меня интересует, в чём разница между «новым письмом» и «ответом на письмо». Я бы сказал, что единственное существенное различие — это получатель. Однако оба типа писем обрабатываются одним и тем же обработчиком (mail-receiver) и отправляются в один и тот же API: https://forum.acme.org/admin/email/handle_mail.

5

Вы тоже это перенесли? Обновили ли вы MX-записи?

Изменили ли вы имя хоста вашего форума?

6
  • Почтовый получатель также был перенесен.
  • Имена хостов остались прежними.

Проблема не в части MX. Письма действительно доходят до mail-receiver, как показывают логи, но как только они отправляются в API, возвращается ошибка 400 (что означает некорректный запрос).

7

Однако в настройках есть разница: я поставил перед ним обратный прокси (nginx), чтобы получить функциональность «временного отключения» и, возможно, разместить другие сайты на том же хосте. Всё равно не понимаю, в чём может быть проблема, ведь новые темы принимаются без сбоев. Тем не менее, я проверю, что произойдёт, если исключить обратный прокси из схемы…

Обновление
Увы! Я перенёс установку Discourse из-за обратного прокси nginx (фактически пересоздав app с правильными настройками и остановив nginx), но это совсем не решило проблему!
Теперь я действительно в тупике. Что здесь происходит?

Краткое резюме:

  • Наша предыдущая установка Discourse (app и mail-receiver) могла принимать новые темы и ответы
  • После миграции на новый сервер (абсолютно идентичный) новые темы всё ещё принимаются, но ответы отклоняются с ошибкой 400 Bad Request.
8

Я нашел проблему, вызывающую эту ситуацию.
При тестировании с несколькими почтовыми клиентами я обнаружил, что письма, отправленные через мой настольный клиент (Thunderbird), возвращали ошибку «400 Bad Request», тогда как при использовании веб-клиента ответ успешно доставлялся.
При дальнейшем расследовании выяснилось, что Thunderbird каким-то образом переключился на кодировку Western (Windows-1252) при ответе, в то время как веб-клиент оставался на UTF-8. После принудительного переключения Thunderbird на UTF-8 письмо также было успешно доставлено.

Thunderbird: письмо не прошло

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

Веб-почта

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

Thunderbird: письмо прошло

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

Считаю, что почтовый получатель должен выполнять проверку и очистку кодировки, но я не разработчик на Ruby, поэтому передаю эту часть кода разработчикам :smiley: