Reply by email address broken

Build 2.9.0.beta4 (82ac698d4f)

In the Admin → Settings → Email page

Discourse ignores the Reply by email address if the email address does not contain %{reply_key} and instead will use the default email address in the to and reply-to headers of the emails it sends out.

Here are the steps to replicate the issue and also what works:


Assuming the default email address set in discourse is

When discourse sends emails, the from and the reply-to headers contain instead of


However, if I add %{reply_key} to the reply by email address:

  • reply by email address →{reply_key}

This works as expected and the email now comes from<id> with the reply-to header also set correclty.

I think that reply by email requires the key in order to work and if you don’t have a key it fails back to using the notification email address, which might be set in your app.yml and hidden from the UX.

So what will disabling find related post with key do then?

1 Like

Sounds like I don’t know what I’m talking about, then. :person_shrugging:

I can confirm that it works just fine without the reply_key and disabling the find related post with key option, just that the to and reply-to addresses doesn’t match what’s provided in the reply by email address - instead it defaults to the one in the app.yml

It just sounds like a bug where it’s ignoring the email address provided on this page when the key isn’t used.

1 Like

That’s sounding right to me. I just didn’t know about the find related post option.

2 posts were split to a new topic: Gmail POP3 needs an app password nowadays

I found this out by accident. What that option does is control what happens if the reply key can’t be found in the database.

If you have it enabled it will reject the post. If you have it disabled it will use the email headers to try and figure things out, which is where the warning about the email address comes in. If it falls back to the headers it will match the user account to the from address instead of rejecting it as it would if there was a mismatch with the key. :slight_smile:


which is less than ideal in my case, some provider (mxplan ovh) being a bit strict with their no-spoofing rule, not allowing the user to send an email from<id> (even if plus addressing works on the receiving end)
…took me a while to figure out what was happening (your clue from a few years back)

1 Like