Allow reply-to individual instead of topic/forum (mailing list feature)

I’ve been playing around with the code, and arrived at this:

In line 148 of lib/email/message_builder.rb, this would result in what I would like to do:

      if allow_reply_by_email?
        result['X-Discourse-Reply-Key'] = reply_key
        result['Reply-To'] = ""
        result['CC'] = reply_by_email_address
        result['Reply-To'] = from_value

However, now I’m trying to figure out what the ‘sender email address’ variable would be in ruby world…

1 Like

After lots of support and help from others, I have finally sorted out the rawest form of how to accomplish this. It is presented below as a patch:

diff --git a/lib/email/message_builder.rb b/lib/email/message_builder.rb
index f099b11..2a69249 100644
--- a/lib/email/message_builder.rb
+++ b/lib/email/message_builder.rb
@@ -147,7 +147,15 @@ module Email
       if allow_reply_by_email?
         result['X-Discourse-Reply-Key'] = reply_key
-        result['Reply-To'] = reply_by_email_address
+        if @opts[:private_reply] == true
+          result['Reply-To'] = reply_by_email_address
+        else
+          p = Post.find_by_id @opts[:post_id]
+          result['Reply-To'] = "#{} <#{}>"
+          result['CC'] = reply_by_email_address
+        end
         result['Reply-To'] = from_value

This patch does the following:

  1. By default, users who hit ‘reply to’ will only reply to the sending user.
  2. For a user to post a public message to the mailing list / topic, they would have to hit ‘reply all’.
  3. It does not act on private messages.

Note: This exposes the sender’s email address to all recipients.

Unfortunately, I will implement this patch for our use-case effective immediately.

However, I recognize that it would be amazing if the following were true:

  1. A per-category or site-wide option to select this
  2. A per-category or site-wide option to expose email addresses.
  3. Integration into personal messages rather than via email directly.
  4. When the responding user hits ‘reply all’ and selects both the list and the sending user, the sending user should not receive an email notification from Discourse. Currently, two messages - one via email and one via Discourse - will arrive.

I hope the patch as it is helps somebody. If I could make it a per-category option, would you guys consider folding it into the master branch, @erlend_sh?


Maybe @zogstrip can chime in here since he’s been our :e-mail: guy extraordinaire as of late.

If at all possible, I’d much rather have this tweak done in the form of a plugin. No other reply-by-email solution I’ve ever tried works this way. Your use case is valid, but incredibly rare.


It’s less a question of desire than ability. I’ve searched for documentation about how to develop a plugin as a Rails novice, but had no luck. Obviously I would really prefer not to have to patch core every time…

Could you point me to a simple plugin I could manipulate / use as a base to do this?


Hello all,

I am trying to understand how to properly make this plugin. I’m currently stuck in my plugin.rb, as it seems that I cannot properly replace the MessageBuilder class.

Here is the current plugin.rb (and the repo in general):

I have tried to understand how to do this by reading a few topics I could find in searches, but as of yet no luck:

When I run the plugin, I get the following, which I suspect reflects that the class is not properly replaced:

/vagrant/lib/email/message_builder.rb:20: warning: already initialized constant Email::MessageBuilder::REPLY_TO_AUTO_GENERATED_HEADER_KEY
/vagrant/lib/email/message_builder.rb:20: warning: previous definition of REPLY_TO_AUTO_GENERATED_HEADER_KEY was here
/vagrant/lib/email/message_builder.rb:21: warning: already initialized constant Email::MessageBuilder::REPLY_TO_AUTO_GENERATED_HEADER_VALUE
/vagrant/lib/email/message_builder.rb:21: warning: previous definition of REPLY_TO_AUTO_GENERATED_HEADER_VALUE was here

Any thoughts or advice?

I replaced a class method so it might need to be done a bit differently
(i.e. instance_eval instead of class_eval ?)
* and yes, the names are counter-intuitive


Take a look at this for how I have reopened the Email::Sender class:


Simon, that seems to definitely change things, but now the class is totally unusable with the error:

Jobs::HandledExceptionWrapper: Wrapped NameError: uninitialized constant MessageBuilder

I’ve posted a Gist of the changes I made to mimic yours here:

Definitely this seems like a step forward, since at least I’m manipulating the class, but not sure what I’m doing wrong here. I will also try to understand @Mittineague 's solution and see if I can implement it.

OK, I think I got it going by removing the after_initialize. Thank you!!!


Hmm. Unfortunately still no dice.

I’ve added a byebug both after the class and after the method to see if they are being accessed. If added after the class, it is clear that the class is being tapped. However, after the method, it is not. Have I gotten the namespace wrong somehow?

Here’s is the most recent gist.

Incidentally, this error remains:

/vagrant/lib/email/message_builder.rb:20: warning: already initialized constant Email::MessageBuilder::REPLY_TO_AUTO_GENERATED_HEADER_KEY
/vagrant/lib/email/message_builder.rb:20: warning: previous definition of REPLY_TO_AUTO_GENERATED_HEADER_KEY was here
/vagrant/lib/email/message_builder.rb:21: warning: already initialized constant Email::MessageBuilder::REPLY_TO_AUTO_GENERATED_HEADER_VALUE
/vagrant/lib/email/message_builder.rb:21: warning: previous definition of REPLY_TO_AUTO_GENERATED_HEADER_VALUE was here

Maybe try something like this, just to see that everything is connected:

after_initialize do
  Email::MessageBuilder.class_eval do

    def body
      'hello world'


If you send yourself a password reset email, you should see ‘hello world’ as the text.


OK, a few remarks:

  1. The require line is unnecessary and should be taken out.
  2. There appears to be a bug where the header_args cannot be inserted into a plugin as currently written. I will report this as a bug after a bit more testing and see what others suggest as a fix

Finally, success!!!

I discovered the error logs (wow… how did this take so long!) They are at: on a vagrant install.

I saw the following error:

Job exception: uninitialized constant MessageBuilder

Which led me to add Email::

Now, the plugin is working!!! Thank you @simon and @Mittineague!!! Now the plugin’s first working version is done. I will post more soon.


Here is the plugin, which is working as best as I can tell:

Thank you again to all of those who have helped!


I’m also working with a Discourse site for a large number of users that were comfortable with a GNU/Mailman list. My users are struggling with the volume of email they’re receiving, because others are sending a large number of person to person messages back through our categories using the email reply option.

Unfortunately many of my users have gotten into the very bad habit of always using “Reply All” in their email clients. With GNU/Mailman this didn’t matter. While the option reply_goes_to_list = Poster was set, messages never made it back to the list unless someone intentionally added the list address.

I’m currently running your plugin on a test server. Is there any way to configure Discourse with your plugin so that the CC address won’t get added to messages? The code refers to @opts[:private_reply], but I haven’t figured out how this option gets set to true.


You can see how I added the private reply option with a link in the email footer at

Exposing the email was a limiting factor for me with this plug in.

Also not sure users would understand the reply vs reply-all distinction so I like the link method better.

I tried this method on my test server too, but my users are strongly divided into email and web camps. The email users really don’t want to visit the web site to participate in discussions or reply to posters. They are going to continue to hit reply all in their email clients which makes the experience worse for everyone.

My Discourse site has login required enabled. Mailman didn’t keep email addresses private from the other list subscribers, so exposing them has never been a concern for this group.

Ideally I’d like to have the option to set the reply-to: header to the sender and provide a mailto: link in the footer that goes to the topic. That would keep the private replies off the topic, while still giving email users a way to continue the discussion without forcing them to use the web site.

It would require change to Discourse Core code, but do you think having alias email addresses for members that used Discourse as a type of relay might solve the disclosure concern?

eg. similar to the generated email address when a member is anonymized, recipients would see something like "" or "" instead of the actual email address.

Based on your description, I think that would OK. I’m assuming the generated email address would send a private message from Discourse to the original sender.

Our email users simply assume that replies from their email client will go to the sender not the topic, because that’s how most Mailman lists have worked for years. It would be nice to offer them a way to add to the topic through a mailto link in the message, but this isn’t a requirement for us.

Having Reply All go back to the topic is a problem that may very well be unique to us. My users have learned that Reply doesn’t include everyone on other emails, so they always hit Reply All. Many of these users see the CC field as just another place to enter email addresses. They don’t really understand the difference between TO and CC.