'Reply by email' not working anymore after migration

support
1

Hi,

We’ve just migrated our self-hosted Discourse instance from one server to another. All settings got migrated from the old to the new system, including ‘reply via email’ and ‘allow new posts through email’. We are using the discourse/mail-receiver setup to handle the email part.
Both the reply-to as the new-email functionality worked great in the old system, but we have an issue on the new server: reply-to doesn’t work anymore.

  1. As an unknown user, when I send an email to the for this purpose configured email address, I can see the mail coming in. A new staged user is being created. The message is being posted. Jay!
  2. As Team user, I can reply to this message, and the message is being delivered correctly. Great!
  3. BUT again replying to that email, which should result in a reply in discourse, fails. When the message arrives in mail-receiver, it tries to deliver it through the API, but that fails with the following log errors.

(For privacy reasons, I altered user and domain names)

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

As I said, this whole back-and-forth worked perfectly fine in the old setup. The new setup is exactly the same (local_discourse/app and local_discourse/mail-receiver) as the old one.

  • Could anyone tell me why the handle_mail API would throw a 400 on a reply email?
  • Would it be possible to make the logging more verbose, so I can dig deeper?
2

You should be able to find more information in Admin - Emails - Rejected.

3

No, sorry, it does not even show up as Rejected. I guess that is because it bumps against a 400 Bad Request…

4

I’m wondering what the difference is between the ‘new mail’ and the ‘reply mail’. I would say, the only relevant difference is the recipient. But both go through the same handler (mail-receiver) and are being posted to the same API: https://forum.acme.org/admin/email/handle_mail

5

Did you migrate that too? Did you update the MX accordingly?

Did you change your forum’s hostname?

6
  • Mail-receiver has been migrated as well.
  • Hostnames are the same.

The problem is not in the MX part. The mail does arrive at mail-receiver, as the logs show, but as soon as it submits the mail to the API, it’s greeted with a 400 (which means a bad request).

7

There is a difference, though, in the setup: I have put a reverse proxy (nginx) in front of it, to get the ‘temporary offline’ functionality, and possibly have other websites on the same host. I still don’t get why it would be a problem, though, as a new topic is being accepted without any hitch. Still, I’m going to see what happens if I take the reverse-proxy out of the equation…

Update
Too bad! I moved the discourse installation from behind the nginx reverse-proxy (basically rebuilding app with the correct settings and shutting down nginx), but this didn’t fix the problem at all!
Now, I’m really at a loss. What’s going on here?

To summarize:

  • Our previous Discourse installation (app and mail-receiver) could accept new topics and replies
  • After migrating to a new server (all the same-same), new topics are still accepted but replies are being bounced with a 400 Bad Request.
8

I have found the problem that is causing this situation.
While playing with several mail clients, I discovered that mail sent with my desktop client (Thunderbird) encountered the ‘400 Bad Request’, but when I used the web client, the reply came through.
Upon further investigation, I found that Thunderbird somehow switched to Western (Windows-1252) encoding upon replying, while the web client stuck to UTF-8. After forcing Thunderbird to use UTF-8, the mail came through as well.

Thunderbird, mail did not pass

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

Web mail

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

Thunderbird, mail passed

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

I’d say that mail-receiver needs to do some encoding checking and sanitizing, but I’m no ruby developer, so I’ll hand it over to the devs for that piece of code :smiley:

9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.