申し訳ありませんが、以下のトーンには前もって謝罪しておきます。私は少しイライラしているので、そう聞こえます。
Michael Brown via Discourse Meta 2022年7月27日 14:06 より:
すみません、今追いついたところです。いくつか考えを述べますが、すでにいくつか対処されているものもあります…
[quote=“Cameron Simpson, post:8, topic:233499, username:cameron-simpson”]
この2番目のコミットは、私たちが目にした別の問題に対処しているようです。投稿がメールから来た場合、メールユーザーに送信されるアウトバウンドメッセージIDは、作成者のソースメッセージのメッセージIDではありません。
[/quote][quote=“Cameron Simpson, post:11, topic:233499, username:cameron-simpson”]
Message-IDは、メッセージの単一の永続的な識別子です。
[/quote]ここでの難しさは、Discourseから送信されるものは、受信したものとは異なるメッセージであるということです。異なるメタデータ（この目的のためには、To/From/Reply-to/Unsubscribe/など）と異なる本文（ユーザーごとにカスタマイズされていると思いますか？メーリングリストモードではそうならないのですか？）を持っています。
メッセージとは具体的に何でしょうか？5322を絶対的なものとして扱うと：
メッセージはヘッダーフィールドで構成され、オプションでメッセージ本文が続きます。
「Message-ID:」フィールドは、特定のメッセージの特定のバージョンを参照する一意のメッセージ識別子を提供します。
[強調は私による]「特定のバージョン」という部分が、受信したメッセージを異なるMessage-IDで再送信するのは不適切だと考えさせる理由です。ただし、Discourseを「フォーラムソフトウェア」からDiscourseを「メーリングリストソフトウェア」と見なす視点に変えれば、そうすることがある程度理にかなっているので、あなたの言いたいことは理解できます。
残念ながら、これは過度に文字通りの解釈に依存しており、おそらく存在しない文脈を読んでいるのでしょう。
_すべての_電子メールメッセージは、メールシステムがそれを処理する際にヘッダーが変更されます。そうでなくても、Received:ヘッダーが各ステップで追加され、いくつかのシステムがスパムフィルタリングの結果や署名を示すさまざまなヘッダーを追加します。これらのいずれもメッセージIDの変更を引き起こさず、実際に行うとメッセージIDは完全に機能しなくなります。
コンテンツに関しては、すでに述べたように、ほぼすべてのメーリングリストが本文にコンテンツを追加します。通常は、リスト管理ページへのリンクや購読解除リンクを含むフッターです。これら も メッセージIDの変更を引き起こしません。
実際、メッセージを転送するほとんど何もメッセージIDを変更しません。それはエンドユーザーのクライアントのスレッド化と重複検出を壊すからです。
私が引用しようとしていたものを、あなたはすでに引用していますね 
5322はまた次のように述べています：
メッセージが「変更」される多くのインスタンスがありますが、それらの変更はメッセージの新しいインスタンスを構成するものではなく、したがってメッセージは新しいメッセージ識別子を取得しません。たとえば、メッセージがトランスポートシステムに導入されると、トレースフィールド（セクション3.6.7で説明）や再送信フィールド（セクション3.6.6で説明）などの追加のヘッダーフィールドが先頭に追加されることがよくあります。そのようなヘッダーフィールドの追加はメッセージのアイデンティティを変更しないため、元の「Message-ID:」フィールドは保持されます。すべての場合において、メッセージの「Message-ID:」フィールドが変更されるかどうかを決定するのは、メッセージに表示される（または表示されない）特定の構文的な違いではなく、メッセージの送信者が伝えたい意味（つまり、これが同じメッセージか異なるメッセージか）です。
おそらく、送信者がDiscourseが送信するときに変わるかどうか、ということになるのでしょう。
ここでは、物事を誤って読んでいると思います。強調させてください：
すべての場合において、メッセージの「Message-ID:」フィールドが変更されるかどうかを決定するのは、メッセージの送信者が伝えたい意味（つまり、これが同じメッセージか異なるメッセージか）であり、メッセージに表示される（または表示されない）特定の構文的な違いではありません。
_送信者_は作成者であり、DiscourseのようなMTAではありません。
メールでDiscourseに投稿する場合、読者にメッセージをそのまま、意味論的に伝えたいです。購読解除リンクのような追加情報は、メッセージで私が言ったことの意味論を変更しません。
それは 同じメッセージ のままです。
Resent-Message-IDとそれに関連するものを使用すべきでしょうか？
絶対に違います。それらは ユーザー がメッセージを再送信するためのものです。たとえば、メッセージを誰かに転送した場合などです。それらはメールリレー（リストやDiscourseなど）用ではありません。
[quote=“Cameron Simpson, post:8, topic:233499, username:cameron-simpson”]
ReferencesもRFC5322に現在含まれているようです。
[/quote]それは常に存在していました。すべて822から。しかし、あなたが後で言うように、はい、更新されました。
痛い。その時点ではUSENETのみだと思っていました。訂正します。
5322は、DiscourseとGithubがそれを使用する方法についても直接述べています：
「In-Reply-To:」フィールドは、新しいメッセージが返信しているメッセージ（またはメッセージ）を識別するために使用される場合があります。一方、「References:」フィールドは、会話の「スレッド」を識別するために使用される場合があります。
おそらく少し不適切ですが、おそらく適切な「スレッド識別子」ヘッダーがないためです。しかし、この解釈はRFCの作成者が意図したものではないかもしれません…「References」はあるが「In-Reply-To」がないメッセージには対応していません。
それは私に、2つのフィールドが同じ情報をカバーしていることを示しています：
Referencesは、OPへの線形（通常）のスレッドを示します。In-Reply-Toは親を示し、前のメッセージからOPまでの全体的な同じスレッドを意味します。
[quote=“Martin Brennan, post:19, topic:233499, username:martin”]
これは興味深いですね。受信者全員がユニークなMessage-IDを持つ必要があると思っていましたか？実際、受信者ごとのMessage-IDに一意性を追加するパスをたどったのはこのためだと信じています。スパムの動作を回避するために、以前の内部トピックを振り返ってみてください。おそらく、インフラチームのメンバーで、今年初めにメールで多くのテストを行っていた@supermathieがここで意見を述べることができるでしょうか？
[/quote]このことの難しい点は、私たちは 1つの メールを送信しているのではなく、N通のメールを送信していることです。つまり、受信者ごとに1通ずつです。これにより、個別のメタデータ（購読解除など）が正しくなります。
これは難しくありません。メッセージの意味は同じであり、カスタマイズはマイナーで意味論的に無関係です。それらは新しいまたは異なるメッセージIDを 正当化しません。
そしてはい、スパム判定がMessage-IDに結び付けられるという強い兆候をテスト中に見ました。後で（同じユーザー または 異なるユーザー）再度見られた場合、スパムとしてマークされる可能性がはるかに高くなります。
これらのインスタンスをいくつか示してもらえますか？メッセージIDはエンドユーザー側での重複排除を可能にするからです。そして、多くの「アンチスパム」対策は誤ったゴミであることを覚えておいてください。壊れたスパム誤フィルタリングのために却下されたものの数は非常に多いです…壊れたメールを修正するためにメールを壊すのは悪い選択です。
今日まで、私はGmailアドレスを持つ人をCCしません。なぜなら、Gmailのスパムフィルタリングは私を知っていて、ものを床に落とすからです。リストにのみ送信すると、それらは届きます。GmailアドレスをCCすると、（a）スパムとしてマークされ、（b）その後、メーリングリストメッセージもスパムとしてマークされます（同じメッセージID！）。エンドユーザーは私のメッセージを見ません。このロジックは完全に誤っていて修復不可能です。
[quote=“Cameron Simpson, post:22, topic:233499, username:cameron-simpson”]
したがって、受信者固有の購読解除リンクを追加して、元のメッセージIDを保持することに完全に満足しています。利点は、各メッセージの コピー に個別のメッセージIDを与えた場合の、スレッド化の損失を はるかに 上回ります。
[/quote]ここでの利点は、正直に言うと、一部のメールクライアントでメールを正しくスレッド化することに完全に焦点を当てており、配信可能性を犠牲にしています。
ため息。すべての メールクライアントに対して。そして、Pythonランドの多くの人々がDiscourseに行かないと言っている 大きな理由 は、メール側のスレッド化が壊れていることです。多くの 人々はフォーラムを使用しません。なぜなら、各フォーラムは 訪問 する必要があるからです。メールは彼らに届き、 彼らの 好みのリーダーと 彼らの 好みのエディタを使用できます。そして、スレッド化により、人々は議論の流れを明確に見ることができます。それが機能するとき。
現在の
topic/#{topic_id}/#{post_id}.s#{sender_user_id}r#{receiver_user_id}は、少なくとも メールボックス内のユーザー にとって一貫性があります。仮定
私の 最大の懸念は配信可能性です。主要プロバイダーからの可視性がゼロの場合、メールを配信するのはすでに十分に困難です。
証拠を見たいです。メーリングリストは世界中でこれを正しく行っています。Discourseは間違いなく、客観的にこれを壊しています。私はそれを修正しようとしています。
ここで2つの基本的な問題を繰り返します：
- OPの
In-Reply-ToとReferencesは、架空の「プリOP」の「トピック」メッセージIDを引用しているため、メールユーザーは開始メッセージ（OP）とのスレッドを持っていません。OPを含む すべて がフォローアップのように見えます。 - Discourse経由で受信したメールと、たとえばCC経由で直接受信したメールは、意味論的には同じメッセージであるにもかかわらず、メッセージIDが異なります。これはスレッド化と重複排除を壊します。
しかし、Discourseがメーリングリストモードでメーリングリストソフトウェアのように動作することには強い議論があると思います。@martin、メーリングリストモードではメッセージ本文をカスタマイズしないと思いますか？メッセージIDの保持と再利用について、より厳格なアプローチを取ることは理にかなっていると思いますか？
Pythonランドには、「メーリングリストモード」が多すぎる火事のホースだと感じた人々がいます。彼らはターゲットを絞ったトピックのメールを受け取りたいのですが、すべてではありません。メッセージIDの処理は、すべての メール側で同じであるべきです。
私はdiscuss.python.orgの「メーリングリストモード」ユーザーです。しかし、ここでは（discourse.org）それを有効にして、 すぐに無効にしました。ここではターゲットモードが必要です。
