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