Discourse のメールメッセージが正しくスレッド化されていません

貢献 バグ
1

discuss python org では、Discourse のメール機能について議論しています。最大の不満は、スレッド表示がないことです。ヘッダーを少し調べたところ、以下のことがわかりました。

  • Message-ID ヘッダーは少なくとも一意です。
  • Reply-To および References ヘッダーは、他のメッセージの Message-ID を参照していません。ましてや、返信対象のメッセージのメッセージ ID を参照しているわけでもありません。
  • 代わりに、トピック番号に基づいた架空のメッセージ ID を参照しています。

これは、メールユーザーが (a) 全くフラットでスレッド表示されない議論を目にし、(b) In-Reply-To および References ヘッダーが実際にはどのメッセージにも存在しないメッセージ ID を参照しているため、ルートメッセージが見当たらないことを意味します。

これは悪いことであり、RFC 5322 に違反しています。そして、メールでの体験を本来あり得るよりもはるかに悪いものにしています。

例として、最初のメッセージに以下のヘッダーを持つスレッドがあります。

Message-ID: <topic/17208.dc83577b18fc3ecc438ed42a@discuss.python.org>
References: <topic/17208@discuss.python.org>

これは最初のメッセージです。どこにもその ID を持つメッセージがないため、References ヘッダーを持つべきではありません。

2 番目のメッセージには、次のヘッダーがあります。

Message-ID: <topic/17208/60568.898edf234f56cf6f3a661c1a@discuss.python.org>
In-Reply-To: <topic/17208@discuss.python.org>
References: <topic/17208@discuss.python.org>

ここでも、Message-ID は問題ありませんが、In-Reply-To および References は完全に無意味です。

これは修正が容易なはずです。最初のメッセージは In-Reply-To も References ヘッダーも持つべきではありません。2 番目のメッセージは、最初のメッセージの Message-ID を In-Reply-To および References ヘッダーに持つべきです。

詳細については、RFC5322 セクション 3.6.4 を参照してください。

現状では、メールユーザーはフラットで構造化されていない議論を目にします。これらの修正により、わかりやすく見やすいスレッド表示が可能になります。

「いいね！」 9
3

もし興味のある方がいらっしゃれば、キャメロンが言及している議論のアーカイブは、https://mail.python.org/archives/list/python-dev@python.org/message/VHFLDK43DSSLHACT67X4QA3UZU73WYYJ/ にあります。

「いいね！」 2
4

それはリグレッションのようですね。この古いトピックと修正を参照してください。

「いいね！」 1
5

HEAD とその修正との差分を確認しています。

topic_canonical_reference_id がフォールバックとして使用されている場合でも、先行するものがなくても、現在の設定では常に References が設定されるようです。その ID を持つメールメッセージは存在しないため、私はまだそれが間違っていると考えています。

In-Reply-To は、post.post_number!=1 の場合にのみ設定されるという点で、もう少し正確ですが、それでも topic_canonical_reference_id にフォールバックします。

@message.header['In-Reply-To'] = referenced_post_message_ids[0] || topic_canonical_reference_id

これは私の目には 2 つの問題があるようです。

  • フォールバックは、referenced_post_message_ids がない場合は topic_canonical_reference_id ではなく、ポスト #1 の Message-ID であるべきです。
  • 返信メールの In-Reply-To ヘッダーを削除している receipt-of-reply-emails コードのどこかに問題があるはずです。なぜなら、それらは referenced_post_message_ids 配列（「リスト」？ Ruby は初心者です）を正しく設定しているはずだからです。
「いいね！」 3
6

キャメロンさん、このトピックを議論のために開いていただき、投稿で多くの詳細を提供していただきありがとうございます。これらの2つのコミットから、この厄介な問題の責任者です。

私たちはしばらくの間、Thunderbirdのようなメールクライアントでスレッディングに関するいくつかの問題があることを認識していましたが、Discourseからのメールスレッディングの消費者はそれほど多くなかったため、延期されていました。しかし、これが明らかになった今、私たちは問題の再検討と修正に取り組むために時間を費やす必要があります。

興味深いことに、Gmailでスレッディングが正しく機能するため、最初の送信メールとそれに続くすべてのメールにこのReferencesヘッダーを追加しましたが、理想的ではないことは認めます。また、後続のメールのIn-Reply-ToおよびReferencesヘッダーで元のMessage-IDを使用していないことも、スレッディングの問題を引き起こしている可能性があります。

古い議論やコードを調べ、この問題を解決していく間、しばらくお待ちください。その間、使用中で問題が発生している他のメールクライアントについて認識していますか？例えば、これがThunderbirdの問題であることは知っていますが、他に何かありますか？ありがとうございます。

「いいね！」 7
7

長い返信を書きましたが、以下のエラーが発生しました。

申し訳ありませんが、["incoming+8349bd9eb1f2b582df4f32dbe85c3363@meta.discoursemail.com"] へのメールメッセージ（件名: Re: [Discourse Meta] [bug] Discourse email messages are incorrectly threaded）は機能しませんでした。

理由:
申し訳ありませんが、新規ユーザーは投稿に2つのリンクしか含めることができません。
問題を修正できる場合は、もう一度お試しください。

フォーラムに移動して修正します…

「いいね！」 1
8

Cameron、このトピックを議論のために開いていただき、投稿で多くの詳細を提供していただきありがとうございます。私は、これらの2つのコミットから、この厄介な問題の責任者です。

3b13f1146b2a406238c50d6b45bc9aa721094f46

これは問題なさそうです。このIDをDBレコードに保存して、受信した返信を元のフォーラムメッセージに関連付けることができますか？

また、サフィックスがRFC5322の構文的に合法であること、つまり許可される文字に関して、私が検証することを望みますか？

82cb67e67b83c444f068fd6b3006d8396803454f

この2番目のコミットは、私たちが経験した別の問題に対処しているようです。投稿がメールから送信された場合、メールユーザーに送信されるアウトバウンドメッセージIDは、作成者のソースメッセージのメッセージIDではありません。これは、メールクライアントの観点から2つの異なるメッセージにつながり、おそらく元のメッセージへの返信と、フォーラムから送信されたコピーへの返信を壊します。たとえば：

To: the forum
CC: one of the participants

参加者は、フォーラムからのコピーと作成者からの直接のコピーを受け取るでしょう（おそらく）、そしてこれらは異なるメッセージIDを持つため、彼らの側では別々のメッセージになります。

私は、この問題について2番目のバグレポートを作成するつもりでした。これは、in-reply-toとreferencesヘッダーの問題を解決した後です。これははるかに重要です。

私たちは、Thunderbirdのようなメールクライアントでしばらくの間、メールスレッディングに関するいくつかの問題に気づいていましたが、Discourseからのメールスレッディングの消費者はそれほど多くなかったため、延期されていました。しかし、これが明らかになった今、私たちはこの問題を見直し、修正に取り組むために時間を費やす必要があります。

私は、そして他の数人もmuttを使用しています。このデバッグとコードレビューを支援するために必要なことは何でも喜んで行います。また、過去の生活で長年メールシステムの管理者をしていました。

[quote=“Cameron Simpson, post:1, topic:233499,
username:cameron-simpson”]
これは最初のメッセージです。Referencesヘッダーはありません。なぜなら、そのIDを持つメッセージはどこにも存在しないからです。
[/quote]

興味深いことに、私たちはこのReferencesヘッダーを最初の送信メールと、それ以降のすべてのメールに追加しました。なぜなら、これによりGmailでスレッディングが正しく機能するからです。

正しいReferencesヘッダー（最初の投稿では欠落しており、返信ではin-reply-toと同様）も機能するはずだと思います。しかし、Gmailは時々メール標準に対してかなり緩い関係を持っています。私はGmailアカウントを持っています。そこでもデバッグを行うことができます。そして原則として、私たちはこの議論自体をテストベッドとして使用できるかもしれません。

しかし、それが理想的ではなく、スレッディングの問題を引き起こしている可能性が高いことは同意します

元のMessage-IDを後続のメールのIn-Reply-ToおよびReferencesヘッダーで使用していないことと並んで。

その間、古い議論とコードを調べ、この問題を解決していきますので、しばらくお待ちください。

心配いりません。

その間、他のメールクライアントが使用されており、問題が発生していることに気づいていますか？たとえば、Thunderbirdでこれが問題であることは知っていますが、他のクライアントはどうですか？ありがとうございます。

間違いなくmuttです。少なくともmuttでは、ヘッダーを表示し、返信ツリーチェーンを表示することが非常に簡単です。これは他のクライアントではしばしば隠されています。

メールスレッディングは、Message-IDおよびIn-Reply-Toヘッダーによって完全に定義されます。ReferencesヘッダーはUSENETでフォローアップのために始まり、（そこでは）複数のメッセージIDをサポートしていました。In-Reply-Toは1つだけをサポートします。ReferencesもRFC5322に現在存在しているように見えます。そして、そのセマンティクスを調査します。

「いいね！」 5
9

後で投稿する予定の大きな投稿のために、考えをまとめているところです。今のところ追加情報ありがとうございます！

「いいね！」 1
10

わかりました、これはかなり大きな問題です。しばらくお付き合いください。まず、もう一つの詳細な返信とデバッグ/レビューの申し出、本当に助かります :+1: 実は今朝これを調べていたのですが、驚くべきことに、Thunderbird ではほとんどの場合、統合ビューでのスレッディングが機能しており、References ヘッダーが OP を一貫して指していることが役立っていると思います (たとえば、このチェーンのトピック Reference は常に \u003ctopic/53@discoursehosted.martin-brennan.com\u003e です)。

image
image3042×492 188 KB

意図したとおりにスレッディングが機能しないケースは次のとおりです。

  1. Discourse 内で投稿が作成され、トピックを監視しているユーザーにメールが送信される。その後
  2. 他の誰かがその投稿に返信し、トピックを監視しているユーザーにメールが送信される。

2 番目のメールの場合、この行 discourse/lib/email/sender.rb at 98bacbd2c6b9fe57167cd32af5eb4839b4a5d1f6 · discourse/discourse · GitHub で新しいものが生成されるため、In-Reply-To および References ヘッダーが正しくありません。最初に送信されたメールの Message-ID を使用する必要があります。スクリーンショットでは、このパターンに従うメッセージはここに配置されるべきです。

image
image2586×389 147 KB

image

答えは「場合による」です。投稿が受信メールから Discourse で作成された場合、たとえばあなたのこの投稿のように、誰かがそれに返信するときに、In-Reply-To および References ヘッダーとしてその投稿の元の受信 Message-ID を使用します。これは次のとおりです。

それ以外の場合は、トピック OP の参照のみを使用し、新しい参照を生成しています。これは明らかにすべての問題を引き起こしている原因です。すべてのケースで、送信メールが送信されるたびに新しい Message-ID を生成しますが、これは他のメールクライアントと同等で正しいようです。

あなたの言っていることが理解できたと思います。次のような流れでしょうか？

  1. cameron が mutt から Discourse にメールを送信し、Message-ID: 74398756983476983@mail.com が付与される。
  2. Discourse が投稿を作成し、IncomingEmail レコードに対して Message-ID を保存する。
  3. johndoe がトピックを監視しているため、Discourse から Message-ID: topic/222/44@discourse.com のメールが送信され、元の Message-ID: 74398756983476983@mail.com への参照はない。

これは正しいでしょうか？独自のものを生成するのではなく、監視しているユーザーにその Message-ID を「渡す」だけでよいのでしょうか？その場合、cameron も元の送信メッセージに彼を CC に入れた場合、johndoe のメールクライアントではどうなりますか？これは別の問題のようですが、別のバグトピックとして開くのが良いでしょう。

mutt クライアントをローカルでセットアップして、あなたが見ているものと同じものを見るようにします。テキストベースのクライアントでのこの機能はテストしたことがありません (Gmail と Thunderbird のみ)。どのように見えるか見てみたいです。

今日の午前中のこれらの問題に対処するための私の考えは、メールに Message-ID ヘッダーを送信するときに生成されるランダムなサフィックスを廃止し、代わりに送信ユーザーと受信ユーザーの両方の user_id を使用するスキームに変更することでした。この利点は、Message-ID をどこにも保存する必要がないこと (受信メールが投稿を作成する場合を除く) であり、References および In-Reply-To ヘッダーは常に一貫性があるということです。例を挙げましょう。これらのユーザーがいるとします。

  • martin - user_id 25
  • cameron - user_id 44
  • sam - user_id 78
  • bob - user_id 999

そして、このトピック、topic_id 233499 があり、投稿は post_id 100 から OP として始まります。フォーマットは topic/#{topic_id}/#{post_id}.s#{sender_user_id}r#{receiver_user_id} になります。操作の順序は次のようになります。

  1. martin が OP を作成します。
  • cameron には次のヘッダーを持つメールが送信されます。
  • Message-ID: topic/233499.s25r44@meta.discourse.org
  • References: topic/233499@meta.discourse.org
  • sam には次のヘッダーを持つメールが送信されます。
  • Message-ID: topic/233499.s25r78@meta.discourse.org
  • References: topic/233499@meta.discourse.org
  1. cameron がメールで返信します。
  • discourse は mutt から次のヘッダーを持つメールを受信します。
  • Message-ID: 43585349859734@test.com
  • References: topic/233499@meta.discourse.org topic/233499.s25r44@meta.discourse.org
  • In-Reply-To: topic/233499.s25r44@meta.discourse.org
  1. discourse (上記のメールから cameron として) が投稿 101 を作成します。
  • sam には次のヘッダーを持つ discourse からのメールが送信されます。
  • Message-ID: topic/233499/101.s44r78@meta.discourse.org
  • References: 43585349859734@test.com topic/233499@meta.discourse.org
  • In-Reply-To: 43585349859734@test.com
  1. sam が cameron にメールで返信します。
  • discourse は gmail から次のヘッダーを持つメールを受信します。
  • Message-ID: 5346564746574@gmail.com
  • References: topic/233499/101.s44r78@meta.discourse.org topic/233499@meta.discourse.org
  • In-Reply-To: topic/233499/101.s44r78@meta.discourse.org
  1. discourse (上記のメールから sam として) が投稿 102 を作成します。
  • cameron には次のヘッダーを持つ discourse からのメールが送信されます。
  • Message-ID: topic/233499/102.s78r44@meta.discourse.org
  • References: 5346564746574@gmail.com topic/233499@meta.discourse.org
  • In-Reply-To: 5346564746574@gmail.com
  1. bob がトピックに投稿 103 を作成します。誰にも返信していません (ここでは、References に OP メールが両方のユーザーに送信された Message-ID が含まれていることに注意してください)。
  • cameron には次のヘッダーを持つメールが送信されます。
  • Message-ID: topic/233499/103.s999r44@meta.discourse.org
  • References: topic/233500@meta.discourse.org topic/23499.s25r44@meta.discourse.org
  • sam には次のヘッダーを持つメールが送信されます。
  • Message-ID: topic/233499/103.s999r78@meta.discourse.org
  • References: topic/233499@meta.discourse.org topic/23499.s25r78@meta.discourse.org
  1. cameron がメールで返信します。
  • discourse は mutt から次のヘッダーを持つメールを受信します。
  • Message-ID: 6759850728742572@test.com
  • References: topic/233499@meta.discourse.org topic/233499/103.s999r44@meta.discourse.org
  • In-Reply-To: topic/233499/103.s999r44@meta.discourse.org

cameron の受信トレイ

  • martin - トピック OP
  • 送信済み → To: discourse, RE: トピック OP
  • sam - 2 番目の投稿への返信
  • bob - トピック内の特定の投稿ではない返信
  • 送信済み → To: discourse, RE: bob の投稿

sam の受信トレイ

*martin - トピック OP

  • cameron - 2 番目の投稿
  • 送信済み → To: discourse, RE: 2 番目の投稿
  • bob - トピック内の特定の投稿ではない返信

これが正しいと思いますが、これらのヘッダーに書いた内容を確認していただけますか？私が少し確信が持てないのは、References をすべてカバーしたかどうか、そしてもちろん、展開する前に開発ブランチで実際のメールのセットでこれをテストすることです。mutt でのテストもまだ行っていません。

ちなみに、GitHub が通知メールをどのように扱っているかも調べましたが、彼らも同様のことを行っており、その「トピック」(この場合は GitHub のプルリクエスト) に関連するすべてのメールで使用される、常に存在する Reference (discourse/discourse/pull/252@github.com) を持っていることに気づきました。

References: \u003cdiscourse/discourse/pull/252@github.com\u003e \u003cdiscourse/discourse/pull/252/issue_event/7042100517@github.com\u003e
In-Reply-To: \u003cdiscourse/discourse/pull/252/issue_event/7042100517@github.com\u003e
「いいね！」 6
11

Martin Brennan 氏による Discourse Meta の投稿（2022 年 7 月 22 日 06:34）

これはかなり大規模な話なので、辛抱強くお付き合いください。まず、詳細な返信とデバッグ/レビューの申し出に感謝します。非常に助かります :+1: 実は今朝、この件について調べていたのですが、驚いたことに、Thunderbird における統一ビューの threading（スレッド表示）はほとんどのケースで機能しています。そして、References ヘッダーが一貫して OP（オリジナルポスト）を指していることがそれを助けていると思います（例えば、このスレッド内のトピック Reference は常に存在し、<topic/53@discoursehosted.martin-brennan.com> です）。

RFC5322 のセクション 3.6.4 を改めて詳しく読み直しました。これは以前のバージョン（822 や 2822）から進化しており、メールの In-Reply-To ヘッダー、USENET の References ヘッダー、そして現代の「複数の以前のメッセージを引用する返信」が統合されています。

短いまとめ：

  • Message-ID はメッセージの単一の永続的な識別子です。
  • In-Reply-To には、このメッセージが直接返信しているすべてのメッセージ ID が含まれます。つまり、2 つのメッセージに返信した場合、それら 2 つのメッセージ ID が含まれます。
  • References は、OP から直前のメッセージまでの先行するメッセージ ID の返信チェーンです。したがって、確かに常に OP のメッセージ ID で始まるべきです。

したがって、このような議論において、ラベルをメッセージ ID と仮定すると：

OP
  -> reply1
    -> reply2 ---+
  -> reply3      |
    -> reply4    |
      -> reply5 <+

reply5 には以下が含まれます：

  • message-id=reply5
  • in-reply-to=“reply2 reply4”
  • references=“OP reply3 reply4”

「reply1 reply2」を references に含めることも合法ですが（reply5 への他のチェーン）、RFC はこれを明示的に推奨していません。一部のクライアントは、references がいくつかのフラット化されたダイグラフではなく、単一の線形返信チェーンであると期待しているためです。

したがって、references を構築するための私の推奨は、「主要な」先行メッセージの references に、主要な先行メッセージのメッセージ ID を追加することです。これにより、常に正しい順序で線形チェーンが得られます。

image
image3042×492 188 KB

興味深いことに、そこには何らかの threading が存在しているようです。

しかし、注目してください：トップの投稿には小さな「返信である」矢印があります。これは 1 番目の投稿であるにもかかわらずです。これはおそらく「topic」references エントリのためで、TB（Thunderbird）に以前のメッセージがあったと誤認させているのでしょう（もちろん、実際にはありません）。

Mutt 環境では、ほとんど threading が機能していません：

23Jul2022 06:24 Olha via Discus - ┌>[Py] [Users] I need an advise  discuss-users 5.7K
22Jul2022 17:12 Paul Jurczak vi - ├>[Py] [Users] I need an advise  discuss-users 5.5K
22Jul2022 13:21 Rob via Discuss - ├>[Py] [Users] I need an advise  discuss-users 6.8K
22Jul2022 12:53 vasi-h via Disc - ├>[Py] [Users] I need an advise  discuss-users 5.5K
22Jul2022 11:38 Cameron Simpson - ├>[Py] [Users] I need an advise  discuss-users  14K
22Jul2022 10:27 Rob via Discuss - ├>[Py] [Users] I need an advise  discuss-users 6.6K
22Jul2022 06:14 vasi-h via Disc r ┴>[Py] [Users] I need an advise  discuss-users 6.5K

これは、すべてのメッセージの In-Reply-To が架空の「topic」メッセージ ID を直接指しているためです。Mutt はおそらく References を無視しているのでしょう。なぜなら、Mutt はメールリーダーであり、References は USENET ニュースに由来するからです。もしかすると Thunderbird は references を使用しているか、in-reply-to に references 情報を追加しているのかもしれません。

threading を行うには、In-Reply-To または References のいずれか一方を参照するだけで十分です。前者はメール由来、後者は USENET 由来です。あなたは両方をサポートしています（素晴らしいことです！）ので、これらを整合させる必要があります。

（余談ですが、いくつかの Python 関係者が USENET インターフェースを通じてリストを消費しているため、USENET ミラーリングについての議論もあります。これも別のトピックです。）

[…]

[quote=“Cameron Simpson, post:8, topic:233499,
username:cameron-simpson”]
これは良さそうです。この ID を DB レコードに保存して、受信した返信を先行するフォーラムメッセージに紐付けることはできますか？
[/quote]

答えは「場合による」です。Discourse 上でインバウンドメールから投稿が作成された場合（例：あなたのこれのようなもの）、誰かがそれに対して返信する際、In-Reply-To および References ヘッダーには、その投稿の元のインバウンド Message-ID が使用されます。これは以下の通りです：

discourse/lib/email/sender.rb at 98bacbd2c6b9fe57167cd32af5eb4839b4a5d1f6 · discourse/discourse · GitHub

それ以外の場合は、トピックの OP 参照を使用し、単に新しい参照を生成しています。明らかに、これがすべての問題の原因となっています。すべてのケースにおいて、アウトバウンドメールが送信されるたびに新しい Message-ID が生成されます。これは正しいようで、他のメールクライアントと同様です。

残念ながら、そうではありません。あなたがメッセージの発信元（つまり、Discourse 内で作成された）である場合、メッセージ ID を生成するのは問題ありません。メッセージ ID がない場合（違法）、それを作成するのは標準的な慣行です（通常は MTA によって行われます）。しかし、あなたがメッセージを転送している場合（メールで作成された）、既存のメッセージ ID は保持されるべきです。

私の考えでは、あなたは以下の 3 つのことを行う必要があります：

  1. 安定したメッセージ ID を持ち、インバウンドメッセージからのメッセージ ID を置き換えないこと
  2. 正しい In-Reply-To を生成すること。これは即座の先行メッセージ（複数可）から簡単に計算できます。つまり、先行メッセージの Message-ID です。
  3. 正しい References を生成すること。これは簡単に計算でき、先行メッセージの References ＋先行メッセージの Message-ID です。

ポイント 1 について、あなたが引用しているコードを見ると、おそらくメールメッセージ ID は（Python 風の構文、すみません）以下のようになるべきです：

def message_id(post):
    return post.incoming_email.message_id or discourse_message_id(post)

つまり、メールから発信された場合は投稿のメールメッセージ ID を、そうでない場合はあなたがこのメッセージの後半で概説しているアルゴリズムのようなものを使用して Discourse メッセージ ID を使用することです。つまり、(a) 安定しており、(b) 構文的に有効なものです。

その後、In-Reply-To と References フィールドを計算するのは、ポイント 2 と 3 のように単純な機械的な作業です。

あなたの言いたいことはわかります。以下のような流れでしょうか：

  1. cameron が mutt から Discourse にメールを送信し、Message-ID: 74398756983476983@mail.com を取得
  2. Discourse が投稿を作成し、IncomingEmail レコードと共にその Message-ID を投稿に保存

その通りです。

  1. johndoe がトピックを監視しているため、Discourse から Message-ID: topic/222/44@discourse.com のメールが送信され、元の Message-ID: 74398756983476983@mail.com への参照がない

いいえ。johndoe へのメールの Message-ID として IncomingEmail.message_id をそのまま渡す必要があります。それは同じメッセージだからです。

それは正しいでしょうか？つまり、すでに一意であるため、トピックを監視している人々にその Message-ID を「転送」し、独自の ID を生成しないようにすべきでしょうか？では、もし cameron がその元のアウトバウンドメッセージで johndoe を CC した場合、johndoe のメールクライアントでは何が起きるのでしょうか？これは別々の問題のように聞こえるので、別のバグトピックを開くのが良いかもしれません。

転送することにより、元のメッセージ（cameron->cc:johndoe）と Discourse の転送メッセージ（cameron->Discourse->johndoe）は、同じメッセージ ID と同じメッセージ内容を持ちます。受信メールシステムは両方を保存します。メールリーダーは両方を見ますが、両方を表示するか、または 1 つだけ保持するかを選択します（これはメールリーダーの方針決定です - 1 つだけ保持するのが一般的です）。それらは同じメッセージなので、一般的にどちらを保持しても問題ありません。

Discourse を無視して、リスト経由と直接メールの両方を通じてコピーされたメッセージを考えてみてください。それらは同じメッセージであり、同じメッセージ ID を持ちます。

ローカルで mutt クライアントを設定して、あなたが目撃しているものを確認します。テキストベースのクライアント（Gmail と Thunderbird 以外）でこの機能をテストしたことがないので、どのような見た目になるか見るのが楽しみです。

設定のサポートは喜んで行います。スレッド表示を行うには、ソートをスレッド表示に設定する必要があります。Mutt は非常に設定可能です。

今日朝、これらの問題に対処するための私の考え方は、メールで Message-ID ヘッダーを送信する際に生成されるランダムなサフィックスを廃止し、代わりに送信者と受信者の両方の user_id を使用する方式に変更することでした。この利点は、Message-ID をどこにも保存する必要がない（インバウンドメールが投稿を作成する場合を除く）ことであり、したがって References と In-Reply-To ヘッダーが常に一貫することです。

はい、それははるかに良いです。ただし、インバウンドメールのメッセージ ID は、アウトバウンドメールの Discourse 派生のメッセージ ID を上書きすべきであることに注意してください。

（ほとんどのメールシステムは、Discourse トピックメッセージ構造のような周囲のコンテキストがないため（メッセージは単独で扱われる）、ランダムな文字列を使用します。しかし、真に必要なものは永続的な一意性だけです。）

例を挙げてみましょう。以下のユーザーがいるとします：

  • martin - user_id 25
  • cameron - user_id 44
  • sam - user_id 78
  • bob - user_id 999

そして、トピック ID 233499 のトピックがあり、ポスト ID 100 から OP が始まるとします。形式は topic/#{topic_id}/#{post_id}.s#{sender_user_id}r#{receiver_user_id} になります。

操作順序は以下のようになります：

  1. martin が OP を作成
  • cameron に以下のヘッダーでメールが送信されます：
    • Message-ID: topic/233499.s25r44@meta.discourse.org
    • References: topic/233499@meta.discourse.org
  • sam に以下のヘッダーでメールが送信されます：
    • Message-ID: topic/233499.s25r78@meta.discourse.org
    • References: topic/233499@meta.discourse.org

  1. OP には References ヘッダーがあってはなりません。threading には不要であり、実際には存在しない「ポスト 0」があるかのように偽ります。つまり、すべての OP が (a) 返信であるかのように見え、実際にはそうではなく、(b) 返信の対象が受信者のメールボックスから欠落しているように見えます。

  2. これは、OP の各アウトバウンドコピーに対して異なるメッセージ ID を作成します。これは悪いです。それらは同じである必要があります。sam が cameron に直接返信で CC したと仮定します。In-Reply-To は、cameron が決して受け取ったことのないメッセージ ID を引用することになります。

単にメッセージ ID フィールドから sender_user_id と receiver_user_id を削除するだけで、すべての受信者が見る単一の一意の ID が得られます。

一意性の制約は個々のメールレベルの「メッセージ」オブジェクトではなく、ポスト自体です。

References について、OP にはそれがあってはなりません。TB（Thunderbird）もその他すべても問題ありません。もし彼らが In-Reply-To の代わりに References を使用してスレッド化している場合でも、返信メッセージ内の References で十分です。

以下は、Mutt でのメーリングリストディスカススレッドの始まりです：

16Jul2022 01:09 Rob Boehne      - │├>[Python-Dev] Re: [SPAM] Re: Swit python-dev 9.2K
16Jul2022 01:33 Peter Wang      - │├>                                 python-dev 3.0K
16Jul2022 00:24 Skip Montanaro  - ├>[Python-Dev] Re: Switching to Dis python-dev 4.2K
16Jul2022 04:49 Erlend Egeberg  - ├>[Python-Dev] Re: Switching to Dis python-dev  10K
16Jul2022 04:20 Mariatta        - ├>[Python-Dev] Re: Switching to Dis python-dev  10K
15Jul2022 21:18 Petr Viktorin   - [Python-Dev] Switching to Discourse python-dev 4.2K

メールを新しい順にソートしていることは無視してください。最初の投稿（一番下）に矢印がないことを見てください。そのメッセージには References も In-Reply-To もありません。他のすべてのメッセージには In-Reply-To があります（おそらく References もありますが、これはメールメーリングリストなので必ずしもそうとは限りません。前述の通り、これらは補完的です）。

以前に挙げた Discourse の例を繰り返します：

23Jul2022 06:24 Olha via Discus - ┌>[Py] [Users] I need an advise  discuss-users 5.7K
22Jul2022 17:12 Paul Jurczak vi - ├>[Py] [Users] I need an advise  discuss-users 5.5K
22Jul2022 13:21 Rob via Discuss - ├>[Py] [Users] I need an advise  discuss-users 6.8K
22Jul2022 12:53 vasi-h via Disc - ├>[Py] [Users] I need an advise  discuss-users 5.5K
22Jul2022 11:38 Cameron Simpson - ├>[Py] [Users] I need an advise  discuss-users  14K
22Jul2022 10:27 Rob via Discuss - ├>[Py] [Users] I need an advise  discuss-users 6.6K
22Jul2022 06:14 vasi-h via Disc r ┴>[Py] [Users] I need an advise  discuss-users 6.5K

すべてに先頭の矢印があることを見てください。これは、メールクライアントがそれらがすべて共通の（そして欠落している）ルートメッセージへの返信であると信じているためです。これは、References ヘッダー内の「topic」メッセージ ID が原因です。一方、ポスト 1 は実際には上記で表示されている一番下のメッセージです。

まとめ：

  • あなたの計画は良いですが、メッセージ ID から送信者と受信者を削除する必要があります。それらは不要であり、実際には受信者が問題を引き起こします（送信者は単に冗長です）。
  • References から「topic」疑似メッセージ ID を削除してください。これはメールクライアント（TB も含む、視覚的に明らかでなくても）を誤解させます。
  1. cameron がメールで返信
  • discourse に mutt から以下のヘッダーでメールが送信されます：
    • Message-ID: 43585349859734@test.com
    • References: topic/233499@meta.discourse.org topic/233499.s25r44@meta.discourse.org
    • In-Reply-To: topic/233499.s25r44@meta.discourse.org

はい、これも「topic」参照があってはならないという留保付きです。予想通り、OP のメッセージ ID への参照があります。ただし、それは sam が OP に対して見るのと同じメッセージ ID でなければなりません。

  1. discourse が（上記のメールから cameron として）ポスト 101 を作成
  • sam に discourse から以下のヘッダーでメールが送信されます：
    • Message-ID: topic/233499/101.s44r78@meta.discourse.org
    • References: 43585349859734@test.com topic/233499@meta.discourse.org
    • In-Reply-To: 43585349859734@test.com

ここで間違っています。Message-ID は .incoming_post.message_id フィールドから 43585349859734@test.com でなければなりません。（私の考えでは、これは post.message_id() であり、メール生成ポストの場合は post.incoming_post.message_id を返し、それ以外の場合は Discourse 生成のものを返します）。

考えてみてください：私は 43585349859734@test.com というメッセージ ID で返信を作成して送信します。一貫性の理由から、それをローカルフォルダーにコピーして保持し、そこでは OP への返信として表示されます。理想的には、Discourse も私のポストのコピーを私に送信します（これは多くのメーリングリストの方針設定です）。したがって、Discourse のバージョンも取得します。それは同じメッセージ ID を持つべきです。それは同じメッセージだからです。単に異なるルートを経由しているだけです。

Discourse のメッセージは私のメッセージへの「返信」ではありません。それは私のメッセージそのものであり、単に転送されたものです。

この効果は、あなたの以降の例全体に波及します。実際のプロセスは、あなたが作ったものよりも単純であるべきです。

次のように考えてみてください。私がメールからポストに返信する場合、それは実質的に私が Discourse を介して sam（および他の人々）にメールを送っているのと同じです。Discourse は私のメッセージをメール受信購読者に転送し、「偶然にも」フォーラムにコピーを保持します :slight_smile:

余談ですが、GitHub が通知メールで何を行っているかについても調べました。彼らは同様のことをしていることに気づきました。つまり、その「トピック」（この場合は GitHub プルリクエスト）に関連するすべてのメールで使用される、常時存在する Reference（discourse/discourse/pull/252@github.com）があります：

References: <discourse/discourse/pull/252@github.com> <discourse/discourse/pull/252/issue_event/7042100517@github.com>
In-Reply-To: <discourse/discourse/pull/252/issue_event/7042100517@github.com>

ああ、GitHub。彼らのイシューメールは本当に災難ですね :slight_smile:

ただし、彼らのシナリオでは、PR が OP です。したがって、プルリクエストへの直接参照は合理的です。ポスト 1 に対して「topic」メッセージ ID を使用することもできます。ただし、「topic/1」ID も同時に使用しない場合に限ります。しかし、あまり意味はないようです。ポスト 1 を特別扱いするのは余計な労力です。私は自分で「topic/1」を使用するでしょう。

複雑さを追加します。私の理解では、管理者はポストやトピックを移動できます。それは「メッセージ ID を生成する」方式、特にポストだけを移動した場合に壊れないでしょうか？私の意見では、すべてのポストが _message_id フィールドを持つべきです。これは、インバウンドメッセージ（メールから）から埋め込まれるか、または（Discourse 経由での投稿の場合）生成されます。そうすれば、それは永続的で安定しており、ポストの入れ替えやアルゴリズムの変更に対して堅牢です。

最後に、小さなセキュリティ上の考慮事項があります：既存のポストのメッセージ ID を主張するインバウンドメールのメッセージ ID は無視すべきです（そして、場合によってはそのメッセージをバウンスさせるべきです）。著者として、私はそのヘッダーに何でも入れることができるからです :slight_smile: 私は単にメッセージ ID を削除することをお勧めします。ポストを受け入れはしますが、他のポストであるように嘘をつかせないでください。Discourse 生成の ID をコピーに割り当て、通常通り進めてください。

「いいね！」 7
12

素晴らしい、詳細な回答をありがとうございます。これを処理して実行可能な項目に変えるにはしばらく時間がかかると思いますので、しばらくお待ちください（また、現在取り組んでいる他の優先度の高い内部プロジェクトもあります）。この情報があれば、スレッドシステムをより堅牢で仕様に準拠したものにできると考えています。投稿を読み進める中で、さらに質問があるかもしれません。キャメロンより

「いいね！」 2
15

Martin Brennan 氏による Discourse Meta への投稿 (2022/07/25 00:28):

この素晴らしい詳細な回答に、改めて感謝いたします。
これを処理して実行可能な項目に落とし込むには、しばらく時間がかかると思いますので、しばらくお待ちください（これ以外にも、現在取り組んでいる優先度の高い内部プロジェクトがいくつかあります）。
この情報があれば、スレッドシステムをより堅牢で仕様に準拠したものにできると考えています。
投稿を読み進める中で、さらに質問させていただくかもしれませんが、Cameron さん、ありがとうございました。

承知しました。Cameron Simpson

「いいね！」 1
16

ちなみに、このフォローアップ投稿には以下のヘッダーが含まれていることに気づきました。

Message-ID: <topic/233499/1137586.d14eea2849d76c355ec214fb@meta.discourse.org>
In-Reply-To: <YttEVzlTh/ymDSPT@cskk.homeip.net>
References: <topic/233499@meta.discourse.org>
      <YttEVzlTh/ymDSPT@cskk.homeip.net>

つまり、元のメールのメッセージIDが保持されており、In-Reply-To は正しい値であり、References には少なくとも私のメールメッセージIDが含まれています。

これは、discuss.python.org で観測されていたこととは異なります。

よろしく、
Cameron Simpson

「いいね！」 1
19

ああ、それは興味深い観察ですね。その小さな矢印には気づきませんでした。

これも非常に興味深いです。ソースを確認せずに推測ですが、Thunderbirdはそうしていると思いますし、GmailのUIも同様のことをしているので、おそらくそうでしょう。

私たちはこれを実行しているようですが、一貫性がないのでしょうか？基本的に、次のことを確認する必要があります。

  • TODO #1 - 投稿に関連するIncomingEmailレコードがある場合、メール送信時に常にそのMessage-IDを使用します。
  • TODO #2 - トピックのOPに関連するメール送信時には References を使用しないでください。 @cameron-simpson 1つ質問があります。もしOPが受信メールによって作成された場合、OPの References にその Message-ID を使用しますか、それとも引き続き除外しますか？

これは興味深いですね。すべてのメール受信者が一意の Message-ID を持つ必要があると思っていましたか？実際、スパム行為を避けるために、各受信者の Message-ID に一意性を追加する方向に進んだと記憶しています。おそらく、今年の初めにメールのテストをたくさん行っていたインフラチームの @supermathie も意見を述べることができるでしょう。

あなたが言っているのは、投稿がすべての受信者の単一の Message-ID を決定するものであるということですか？では、メールが送信される各投稿に対して1つ生成するだけでしょうか？そうすれば、IncomingEmail.message_id もここに移動できます。暫定的に、変更する必要があるのは次のとおりです。

  • TODO #3 - Postテーブルに outbound_message_id を追加します。投稿に関連するメールが最初に送信されたときに一度生成します。これを後続の References および In-Reply-To ヘッダーに使用します。IncomingEmailから投稿が作成されたときにその値を設定します。フォーマットは topic/:topic_id/:post_id/:random_alphanumeric_string@host のようになります。例：topic/233499/33545/gvy8475y7c45y87554c@meta.discourse.org

この変更後、私の最初の例は次のようになります。

  1. martin がOPを作成します。
  • cameron には次のヘッダーを持つメールが送信されます。
    • Message-ID: topic/233499/33545/gvy8475y7c45y87554c@meta.discourse.org
  • sam には次のヘッダーを持つメールが送信されます。
    • Message-ID: topic/233499/33545/gvy8475y7c45y87554c@meta.discourse.org

OPに特別な処理がないという考慮事項も合わせて、もはや topic/:topic_id@hostname の形式ではなくなります。

  • TODO #4 - PostReplyレコードとPostテーブルの新しいoutbound_message_id列に基づいて、正しいIn-Reply-ToおよびReferencesヘッダーが生成されることを確認します。

これについては考慮していると思いますが、再確認します。

間違いなくそう思えます :sweat_smile:

ここでのTODOは妥当に聞こえますか、Cameron？見ていると、それほど多くないように思えます。また、この作業に着手したときに、WIPの変更がデプロイされたテスト用Discourseインスタンスに私を招待して、メールをやり取りして、すべてが正しく機能していることをテストしてくれることに興味がありますか？もちろん、あなたを巻き込む前に自分でテストを行います。

もしそうでなくても構いません。Thunderbirdを持っており、mutt をセットアップして、すべてをテストできます :slight_smile:

「いいね！」 1
20

@cameron-simpson ここで明確にしたい点が1つあります。「message_id」のスコープについてです。

この一連のやり取りのきっかけとなったのは、@supermathie による、一意でない message_id が問題を引き起こしているのではないかという強い疑念でした。

Discourse は、送信するすべてのメールに対して、ユーザーごとに一意のメールを生成します。たとえば、このトピックをウォッチしているユーザーが2人いるとします。

  • ユーザー1 は、ユーザー1専用の購読解除リンクが付いたペイロード1を受け取ります。
  • ユーザー2 は、ユーザー2専用の購読解除リンクが付いたペイロード2を受け取ります。

この場合、両方のケースで message id が discourse_topic_100/23（topic_id/post_number）だったとすると、MTAs（メール送信エージェント）に対して、discourse_topic_100/23 が2つの異なるペイロードになり得ることを伝えていることになります。これはスパム信号として扱われるという仮説があります。

おい Discourse… discourse_topic_100/23 という名前のメールを2通送ったが、どういうことだ？

Discourse はすべてのメール転送を制御しており、従来のメーリングリストのようにメールが BCC や CC リストに追加されることはないため、ユーザーごとにクリーンな購読解除リンクを用意することができます。

これについてどう思いますか？たとえば、メールの一意の識別子として discourse_topic_100/23/7333（topic_id, post_number, user_id）を使用するという簡単な変更はどうでしょうか。これは間違いなく一意のペイロードであり、ユーザー向けのメールを生成する際に簡単に参照できます。

「いいね！」 1
21

Martin Brennan による Discourse Meta からの投稿、2022 年 7 月 26 日 00:27

これも非常に興味深いです。ソースを調べていませんが、Thunderbird はそうしていると思いますし、Gmail UI もおそらく同様に行っているでしょう。

Mutt は両方を使用すると思いますが、もし存在すればおそらく In-Reply-To を優先し、それを References にフォールバックするでしょう。ソースを確認する必要があります。

References を使用すれば、少なくとも OP までの完全なチェーンを知ることができます。一方、In-Reply-To の場合は、物事を結びつけるために前後の先行メッセージが必要になります。メーリングリストの場合、私は通常、スレッド全体が完了するまでローカルに保持しますが、それは一般的なことだと思います。

私たちはこれを行っているようですが、一貫性がないのかもしれません？基本的には以下のことを確認する必要があります。

  • TODO #1 - ポストに関連する IncomingEmail レコードが存在する場合、メール送信時には常にその Message-ID を使用する。

はい。そのため、message-id 用の明示的なフィールドを持ち、一度だけ埋めておくのが最も合理的だと考えていました。その後、コード内で message-id が生成されるプロセスが変更されたとしても、常にそれを使用します。

  • TODO #2 - トピックの OP に関連するメールを送信する際に References を使用しない。

はい。OP には先行するものがないため、References も In-Reply-To も存在しません。

@cameron-simpson 一つ質問ですが、OP が受信メール経由で作成された場合、OP の References にその Message-ID を使用しますか、それとも引き続き除外しますか？

引き続き除外します。ただし、OP の永続的な message-id として使用します。

つまり、メールで書かれたメッセージ（OP または返信）は、メールから message-id を取得します。ウェブ上で書かれたものは、ユーザーが送信ボタンを押したときに Discourse によって生成されます。それ以降は、どのように生成されたにせよ、その message-id がそのまま使われます。

興味深いですね。私は、メールのすべての受信者が一意の Message-ID を持たなければならないと思っていました。

いいえ。message-id は「メッセージ」を識別します。個々のコピーではありません。私がフォーラムに投稿し、誰かに直接 CC を送ったとします。その誰かが私から直接コピーを受け取り、フォーラム経由でも受け取った場合、それらは同じ message-id を持つべきです。

実は、これがスパム行為を避けるために各受信者の Message-ID に一意性を追加する方向に進んだ理由だと思います。私たちの内部トピックを振り返ってみると。おそらく、インフラチームに所属し、今年初めにメールのテストを多く行っていた @supermathie もここで意見を述べてくれるかもしれません。

もしかしたら。しかし、表面的には、スレッド化は確かに壊れています。確かに、同じメッセージを多くの人に送信する場合は同じ message-id を持つべきであり、一般的に、フォワーダー（メール→Discourse→メール受信者）として、Discourse が message-id を変更すべきではありません。

あなたが言っているのは、すべての受信者に対して単一の Message-ID を決定するものはポストであるべきだということです。したがって、メールを生成する各ポストに対して、単一の message-id を生成すればよいのでしょうか？

すべてのポストは、メール側で使用する安定した一意の message-id を持つべきです。ポストがメールから来た場合、元の message-id を使用するべきです。それ以外の場合（ウェブインターフェース経由）、Discourse が message-id を生成し、ポストに保存すべきです。

それから、IncomingEmail.message_id もここに移すことができます。

もちろん。メール側の状態を含む独立したフィールドセット（message-id で十分そうです）を持てば問題ないでしょう。

暫定的に、私たちが行う必要がある変更は以下の通りです：

  • TODO #3 - Post テーブルに outbound_message_id を追加する。ポストに関連してメールが最初に送信された際に一度生成する。

もしポストをメールから 取得した のであれば、新しいものを生成するのではなく、それを使用すべきです。

以降の References と In-Reply-To ヘッダーに使用します。IncomingEmail からポストが作成された際にその値を設定します。

はい。メールからの message-id に設定します。

フォーマットは topic/:topic_id/:post_id/:random_alphanumeric_string@host のようにします。例：topic/233499/33545/gvy8475y7c45y87554c@meta.discourse.org

自分で生成するものについては、これで良さそうです。

この変更後、私の最初の例は以下のようになります：

  1. martin が OP を作成
  • cameron に以下のヘッダーを持つメールが送信される：
    • Message-ID: topic/233499/33545/gvy8475y7c45y87554c@meta.discourse.org
  • sam に以下のヘッダーを持つメールが送信される：
    • Message-ID: topic/233499/33545/gvy8475y7c45y87554c@meta.discourse.org

はい。

ただし注意点：message-id は安定しており一意であれば十分です。topic/:topic_id/:post_id@host が安定しており、決して再生成されないならそれで構いません。しかし、それに懸念がある場合（例えば、DB のリストア、マイグレーション、インポートで同じ番号が持ち込まれる場合など）、ランダムな文字列があれば衝突に対して堅牢になります。

message-id の左側は dot-atom-text であり、ここで定義されています：

これはアルファベットと数字、そして限られたセットの句読点（「/」を含む）で構成されます。

ええと、あなたのヘッダーについて。以下のようにする必要があります：

Message-ID: <topic/233499/33545/gvy8475y7c45y87554c@meta.discourse.org>

角括弧に注意してください。message-id は形式的には角括弧の間にある部分であり、角括弧は必須です。構文はこちら：

OP に特別な処理がないことを考慮すると、もはや topic/:topic_id@hostname の形式にはなりません。

良さそうです。

  • TODO #4 - PostReply レコードと Post テーブルの新しい outbound_message_id カラムに基づいて、正しい In-Reply-To および References ヘッダーが生成されることを保証する

ありがとうございます。

私はそれについて何か考慮していると思いますが、再確認します。

+1

確かにそう見えますね :sweat_smile:

Cameron、ここに挙げた TODO は妥当だと確認できますか？

私には正しいように思えます。

今見てみると、それほど多くないようですね。また、この作業に取り掛かった際、WIP の変更がデプロイされたテスト用の Discourse インスタンスに参加して、メールのやり取りを行い、機能が正しく動作しているかテストすることに同意してくれますか？もちろん、あなたを巻き込む前には自分でテストを行います。

もちろん。どんな形でも喜んでお手伝いします。

もしダメでも構いません。私は Thunderbird を持っており、mutt もセットアップする予定です。そこで全てテストします :slight_smile:

必要であれば、mutt のお手伝いもできますよ。

「いいね！」 3
22

同じメッセージIDでも、これくらいのわずかな違いがあれば、依然として個別のメッセージを送信できると思います。

通常のメーリングリストでは、程度の差こそあれ、常にこのようなことが行われています。少なくとも、ヘッダーの操作は常に行われています。しかし、メッセージ本文が変更されることもあります。例えば、python-list ではテキスト以外の添付ファイルが破棄されます。メッセージは同じメッセージIDで通過します。そして、ほとんどのリストでは、リスト管理ページへのリンクや購読解除リンクなどが末尾に追加されます。これは、メッセージが到着したときには存在しなかったものです。

また、署名で何をカバーすべきかという、コンテンツ署名に関する長い議論もありました。

そのため、受信者固有の購読解除リンクを追加し、元のメッセージIDを保持することには全く問題ありません。もし各メッセージのコピーに個別のメッセージIDを付与した場合に失われるスレッディングよりも、メリットの方がはるかに大きいのです。

繰り返しますが、メールユーザーのことを考えてください。ディスコースのメッセージに返信して、関心のある外部の人にCCを追加することができます。その人はディスコースからコピーを受け取るかもしれませんが、受け取らないかもしれません。しかし、もし受け取った場合、追加のライダーがあっても、ソースメッセージIDが記載されているはずです。そうでなければ、その人は私のメッセージのコピーを2つ持つことになりますが、メールシステムはそれらが同じメッセージのコピーであることを認識しません。これは問題を引き起こします。

したがって、要するに、あなたの非常にわずかな追加の購読解除テキストは、個別のメッセージIDを必要とするほどのものではないということです。1つだけ保持してください。

「いいね！」 4
23

申し訳ありません、今追いつきました。いくつか考えを共有します。すでに解決済みのものもあります…

ここでの難しさは、Discourseから送信されるものは、受信したものとは異なるメッセージであるということです。異なるメタデータ（この目的のためには、To/From/Reply-to/Unsubscribe/など）と異なる本文（ユーザーごとにカスタマイズされています（そうだと思いますか？メーリングリストモードではこれは行われませんか？））を持っています。

メッセージとは何でしょうか？ 5322を聖典として扱うと：

メッセージは、ヘッダーフィールドと、オプションでメッセージ本文で構成されます。

「Message-ID:」フィールドは、特定のメッセージの特定のバージョンを参照する一意のメッセージ識別子を提供します。

[強調は私によるものです]

「特定のバージョン」という部分が、受信したメッセージを異なるMessage-IDで再送信するのは不適切だと私に思わせます。ただし、Discourseを「フォーラムソフトウェア」からDiscourseを「メーリングリストソフトウェア」と見なす視点に切り替えれば、そうすることがある程度理にかなっているので、あなたの考えは理解できます。5322はまた次のように述べています：

メッセージが「変更」されるインスタンスは数多くありますが、それらの変更はメッセージの新しいインスタンスを構成するものではなく、したがってメッセージは新しいメッセージ識別子を取得しません。たとえば、メッセージがトランスポートシステムに導入されるとき、それらはしばしばトレースフィールド（セクション3.6.7で説明）や再送信フィールド（セクション3.6.6で説明）などの追加のヘッダーフィールドを先頭に追加されます。そのようなヘッダーフィールドの追加はメッセージのアイデンティティを変更しないため、元の「Message-ID:」フィールドは保持されます。すべての場合において、メッセージの送信者が意図する意味（つまり、これが同じメッセージなのか別のメッセージなのか）が、メッセージに現れる（または現れない）特定の構文の違いではなく、Message-ID:フィールドが変更されるかどうかを決定します。

送信者がメッセージをDiscourseから送信するときに変わるかどうか、ということになると思います。

Resent-Message-IDと関連ヘッダーを使用すべきでしょうか？

それは常に存在していました、822以来ずっとです。しかし、あなたが後で言うように、はい、それは更新されました。

5322は、DiscourseとGithubがそれを使用する方法についても直接言及しています：

「In-Reply-To:」フィールドは、新しいメッセージが返信しているメッセージ（またはメッセージ）を識別するために使用できます。一方、「References:」フィールドは、会話の「スレッド」を識別するために使用できます。

おそらく少し不適切ですが、適切な「スレッド識別子」ヘッダーがないためでしょう。しかし、この解釈はRFCの作成者が意図したものではないかもしれません…「In-Reply-To」なしで「References」を持つメッセージには対応していません。

このことの難しい点は、私たちが1つのメールを送信しているのではなく、受信者ごとにN通のメールを送信していることです。これにより、個々のメタデータ（Unsubscribeなど）が正しくなります。

そしてはい、スパム判定がMessage-IDに関連付けられるという強い兆候をテスト中に見ました。後で（同じユーザーまたは異なるユーザー）再度表示された場合、スパムとしてマークされる可能性がはるかに高くなります。

正直なところ、ここでのメリットは、配信可能性を犠牲にして、特定のメールクライアントでメールを正しくスレッド化することに完全に関連しています。

現在のtopic/#{topic_id}/#{post_id}.s#{sender_user_id}r#{receiver_user_id}は、少なくともユーザーのメールボックス内では一貫性があります。仮定

私の最大の懸念は配信可能性です。主要プロバイダーからの可視性がゼロの場合、メールを配信することさえ困難です。

しかし、Discourseをメーリングリストソフトウェアのようにメーリングリストモードで動作させることには強い議論があると思います。@martin、メーリングリストモードではメッセージ本文をカスタマイズしていないと思いますが？メッセージIDを保持および再利用することに関して、より厳格なアプローチを取ることは理にかなっていると思いますか？

「いいね！」 5
24

ここでは、完璧を「十分良い」ことの敵にしたくないのです。

現在、メッセージに「ランダムな接尾辞」を使用しており、これが間違いなく問題を引き起こしています。

以下の3つの選択肢があります。

  1. 参照できないランダムなメッセージID
  2. トピック/投稿/ユーザーごとに安定したメッセージID
  3. トピック/投稿のペアごとに安定したメッセージID

現在、私たちは(1)の状況にあり、大混乱を引き起こしています。

(2)と(3)の間で意思決定麻痺に陥るのではないかと心配しています。

おそらく、追加のCCをDiscourseからのメールに追加すると予期しない動作が発生する可能性があることを認めつつ、まず(2)から始めることで、少なくとも大部分の問題を停止できるのではないでしょうか。

「いいね！」 4
25

ああ！すでに topic/#{topic_id}/#{post_id}.s#{sender_user_id}r#{receiver_user_id} を実行していると思っていました。

メールの一意性と配信可能性の懸念とメーリングリストモードの懸念のバランスを取るために、メーリングリストモードが無効の場合は（2）、メーリングリストモードが有効な場合は（3）を実行する傾向があります。

同様に、References ヘッダーについては、トピックの投稿#1では存在せず、トピック（topic/#{topic_id}）と返信先の投稿を参照するようにする傾向があります。

「いいね！」 3