The discussion revolves around enabling “reply to author” or “reply to all” in email clients for Discourse notifications. thoka proposes using a custom sender address and multiple recipients to allow users to choose between replying to the author or all. However, pfaffman considers this approach flawed and instead shares a plugin, discourse-email-include-address, which adds the sender’s email address to the notification emails, but exposes user email addresses. thoka seeks an alternative solution that does not expose email addresses and suggests modifying email headers instead of templates. pfaffman agrees that modifying email headers is a better approach, but notes that it would still require exposing an email address, making it unsuitable for the Discourse core, but possible as a plugin.
I would like to know how the option to choose between “reply to author” or “reply to all” could be triggered in email clients of the users who receive notifications from Discourse.
Currently, every message comes from the same “do not reply” address, addressing only the recipient.
I would like to read opinions on whether a naive approach using author_of+{reply_id}@my.discourse as the sender and multiple addresses as recipients (the real recipient and a audience_of+{reply_id}@my.discourse) would allow users to choose recipients (author or all) in their clients (in a scenario with email-receiver).
It adds the sender email address to the emails, so people can reply directly if they want. This exposes everyone’s email address, so it’s really appropriate only for people who would rather be using Mailman than Discourse.
It’s likely that the client I wrote it for hasn’t upgraded since November 2020, so I don’t know whether it still works. At first glance, it would appear that it does.
I was searching for a solution that does not expose any user email addresses in general.
Although, special categories could be marked for private replies by email and could additionally expose official email addresses, which, in our case, are (or should be) well known by our users.
In that case, it would not be necessary to handle private or confidential information inside Discourse at all.
The more I think about this, the more I like it.
However, unlike your implementation, I would prefer not to change the email template and instead make this work by changing email headers.
I suppose the from address should still be something like do-not-reply@my.discourse to satisfy DMARC. The reply-to: header would be my.name@official.site, and the to: field would include the recipient and the reply-to-forum email address.
Yes. My “solution” is crude indeed. Another example of my treating Contribute > Feature as Support, I’m afraid.
That’s a good idea. I’m not sure how hard it would be. It would still mean exposing an email address, so I don’t see it moving to core, but should be possible in a plugin. I don’t know offhand how hard that would be