私たちのディスコースは、定期的に交流しないが、時折情報を共有する必要があるさまざまなグループの広範なコミュニティに役立ちます。
問題は、あるカテゴリで受信したメールを、メールイン経由で別のカテゴリに転送すると、メッセージがカテゴリではなく元のトピックに届いてしまうことです。
詳細：
discourse+CATEGORY@... の形式のメールが割り当てられている再現手順：
discourse+CAT-B@... を使用してカテゴリBに転送する質問：転送されたメールが正しいカテゴリBに届くようにするにはどうすればよいですか？（メールヘッダーを変更せずに！）
元のスレッドのカテゴリAに表示されるということでしょうか？
また、何も知らないまま回答していますが、すぐに誰かが実際の状況を教えてくれるでしょう。しかし、私の知る限りでは、そのように進むはずであり、メールを変更するだけで返信が新しいトピックに変わることはありません。
はい、ありがとうございます。修正しました。
補足：
その方は reply-to ではなく、to: アドレスを手動で discourse+cat-B@ のメールアドレスに設定して転送することで、メールに返信します。
これを再現できません。これまでの手順は以下のとおりです。
email time window minsを1分に設定します（オプションですが、高速化します）。
- Fwd: [JammyDodger's Test Site] [categorya] Topic for Category A)。ただし、追加されたメッセージのみが含まれ、意図された転送情報は含まれません）。転送されたメールが既存のトピックへの返信になってしまうという問題を再現できません。代わりに試せることは他にありますか？
試してくれてありがとう！
メールクライアントに関係がある可能性はありますか？「宛先」フィールドではなく、「返信先」フィールドでメッセージをグループ化することをディスコースのせいにしました。
ああ、その設定についてはどうですか？
どうでしょう？テストにはGmailを使用しました。参考になるでしょうか？
私もデフォルトでそのように設定しています。
Nice spot @Moin
I’ve just tried repro-ing this as well (a key difference seemed to be pressing ‘Reply’ and then manually changing the To address, rather than Forwarding), but mine ended up as a new topic in Category B again. Perhaps this does make it client specific? @artur Which are you using?
私もこれを再現しようとしましたが、（返信を押してから手動で宛先を変更したか、転送したかの違いが大きかったようです）私の場合は新しいトピックとしてカテゴリBに届きました。クライアント固有の問題でしょうか？ @artur どちらをお使いですか？
Gmailで試しましたが、メールは元のカテゴリに届きました。
不思議ですね。あなたがうまくいったことに驚いています！
転送されたメールのヘッダーを確認していただけますか？
例えば、References に元のトピックIDが含まれているのですが、これが to: フィールドよりも優先されるのでしょうか？
リンクありがとうございます！\n私の場合は返信ではなくメールの転送に関するものなので、状況は似ているようです。それゆえ、その動作がまだ理解できません。
返信を何度も入力しては、何か別のことを試そうと考えています。
しかし、今のところあなたの問題を再現することはできていません。関連する可能性のあることとして、私のテストサイトではPOP3ではなくmail-receiverを設定しています。また、最初の投稿/OPを転送していますか、それとも返信を転送していますか？
POP3を使用しており、最初の投稿を転送しています。
ご協力ありがとうございます！
こんにちは、@JammyDodgerさん。ほとんどのカテゴリが歴史的に「カテゴリはメーリングリストをミラーします」に設定されていたことに気づきました。このオプションを有効にしたときに問題を再現しようとしていただけますか？テストインスタンスで無効にしてみたところ、奇妙な動作が解決したようです。
Category AとCategory Bの両方でCategory mirrors a mailing listを有効にしてテストしたところ、問題を再現できるようになりました。
CategoryAとCategoryBを設定し、それぞれにメールアドレス（categorya@[MyTestSite]とcategoryb@[MyTestSite]）を割り当てます。Category mirrors a mailing listを設定します。test_userを両方のカテゴリでWatchingに設定します。email time window minsを1分に設定します（任意ですが、処理を速くします）。CategoryAにトピックを投稿します。test_userはCategoryAの新しいトピックの通知メールを受け取り、メッセージとともにCategoryBに転送します。Category Aの元のトピックへの返信として表示されます。メーリングリストについてはあまり詳しくないのですが、これはバグでしょうか、それとも設定の競合でしょうか？
また、@dachary、これもあなたの問題の解決に役立つ可能性があると思いますか？
ご確認ありがとうございます！
さて、ミラーメーリングリストオプションの機能を再読したところ、バグではなく意図された動作のようだと理解しました。
- 通常、
find_related_post_with_keyはサイト設定で有効になっています。この設定をサイト全体で無効にすることは推奨されません。なぜなら、メールアドレスに基づいたユーザーのなりすましを可能にするからです。メーリングリストに送信された受信メールは、常にメールのMessage-IDを使用して関連投稿を見つけ、そのサイト設定の値を無視します。
私がこのオプションを主に保持していたのは、別の点のためです。
- 通常、Discourse は受信メールに Markdown 形式のテキストが含まれていることを期待しています。メーリングリストのユーザーは通常その要件を認識していないため、Discourse は Markdown (3つのバッククォートで囲まれたコードブロックを除く) や HTML をプレーンテキストメール内で解釈せず、元の書式設定をそのまま投稿します。
Markdown を全く知らない人にとっては理にかなっていますね
どういたしまして。 このトピックを Support に移動しました
これで設定がどのように連携するのか、より詳しく分かりましたので、どのように機能させたいかの公平な近似値を得ることができますか？
純粋なメーリングリストミラーサイトとしては、正しく機能していると思います。
ユーザーがマークダウンをどのように扱うか見てみましょう。彼らはこれが期待されていることを全く認識していないでしょう！
実際にメーリングリストミラーを無効にした際に発生した問題は、一部のユーザーに代わって送信される自動生成メッセージの場合に Discourse::InvalidAccess エラーが発生することです。拒否メッセージには次のように表示されます。
そのカテゴリに新しいトピックを投稿する権限がアカウントにありません。
にもかかわらず、同じユーザーで以前は機能していました。したがって、ミラーオプションはその種の保護を無効にしているのだと思います。
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.