Discourse から通知を受け取るユーザーのメールクライアントで、「作成者に返信」または「全員に返信」を選択するオプションをどのようにトリガーできるかを知りたいです。
現在、すべてのメッセージは同じ「返信不可」アドレスから送信され、受信者のみを対象としています。
送信元として author_of+{reply_id}@my.discourse を使用し、複数のアドレス（実際の受信者と audience_of+{reply_id}@my.discourse）を受信者として使用する単純なアプローチで、ユーザーがクライアント（email-receiver シナリオ）で受信者（作成者または全員）を選択できるようになるか、それについての意見を読みたいです。
Add "convert to private Message" to review options も参照してください。
それはあなたの問題に対するかなりひどい解決策だと思いますが、誰かがそれを求めていたので、GitHub - pfaffman/discourse-email-include-address: Include email addresses on emailed notifications を書きました。
送信者のメールアドレスをメールに追加するので、希望すれば直接返信できます。これは全員のメールアドレスを公開するため、MailmanではなくDiscourseを使用したい人にのみ適しています。
私がそれを書いたクライアントは2020年11月以降アップグレードしていない可能性が高いので、それがまだ機能するかどうかはわかりません。一見したところ、機能するように見えます。
共有ありがとうございます。
一般的に、ユーザーのメールアドレスを一切公開しないソリューションを探していました。
ただし、特別なカテゴリは、メールによるプライベート返信としてマークでき、さらに公式メールアドレスを公開することもできます。これは、私たちのケースでは、ユーザーによく知られている（または知られているべき）ものです。
その場合、Discourse内でプライベートまたは機密情報を一切処理する必要がなくなります。
これについて考えるほど、気に入ってきました。
しかし、あなたの実装とは異なり、メールテンプレートを変更するのではなく、メールヘッダーを変更することでこれを機能させたいと思います。
DMARCを満たすために、fromアドレスは依然としてdo-not-reply@my.discourseのようなものであるべきだと思います。reply-to:ヘッダーはmy.name@official.siteになり、to:フィールドには受信者とフォーラム返信用のメールアドレスが含まれます。
はい。私の「解決策」は確かに粗雑ですね。Contribute > Feature を Support として扱ってしまう私の別の例だと思います。
それは良いアイデアですね。どれくらい大変かはわかりませんが、それでもメールアドレスを公開することになるため、コアに組み込まれることはないと思いますが、プラグインとして実装することは可能でしょう。それがどれくらい大変かはすぐにわかりません