Sur discuss python org, nous discutons de la partie e-mail de Discourse. Le principal grief est le manque de filtres. J’ai un peu fouillé dans les en-têtes et il semble que :
l’en-tête Message-ID soit au moins unique
les en-têtes Reply-To et References ne font pas référence aux Message-ID d’autres messages, encore moins à l’ID du message auquel ils répondent
ils font référence à un ID de message fictif basé sur le numéro du sujet
Cela signifie que les personnes utilisant l’e-mail voient (a) des discussions totalement plates et non filetées et (b) le message racine est apparemment manquant, car les en-têtes In-Reply-To et References font référence à un ID de message qui n’apparaît jamais dans aucun message.
C’est mal, et en violation de la RFC 5322. Et cela rend l’expérience de l’e-mail bien moins bonne qu’elle ne pourrait facilement l’être.
À titre d’exemple, il y a un fil de discussion là-bas dont le premier message a ces en-têtes :
Encore une fois, un Message-ID correct, mais des In-Reply-To et References complètement absurdes.
Cela devrait être facile à corriger. Le premier message ne devrait avoir ni en-tête In-Reply-To ni References. Le deuxième message devrait avoir le Message-ID du premier message dans les en-têtes In-Reply-To et References.
Veuillez consulter la section 3.6.4 de la RFC 5322 pour plus de détails :
En l’état actuel des choses, les utilisateurs d’e-mail voient des discussions plates et non structurées. Avec ces corrections, ils peuvent avoir un affichage threadé sensé et facile à suivre.
Au cas où cela intéresserait quelqu’un, les archives de la discussion à laquelle Cameron fait référence se trouvent sur \u003chttps://mail.python.org/archives/list/python-dev@python.org/message/VHFLDK43DSSLHACT67X4QA3UZU73WYYJ/\u003e.
Je jette juste un coup d’œil à la différence entre HEAD et ce correctif.
Il me semble que current définit toujours References, même s’il n’y a pas d’antécédent - topic_canonical_reference_id est utilisé comme solution de repli. Je pense toujours que c’est faux, car il n’y a pas de message e-mail avec cet identifiant.
In-Reply-To est un peu plus correct, en ce sens qu’il n’est défini que si post.post_number!=1, mais il utilise toujours topic_canonical_reference_id comme solution de repli :
la solution de repli devrait être le Message-ID du post #1 s’il n’y a pas de referenced_post_message_ids, et pastopic_canonical_reference_id
quelque chose dans le code de receipt-of-reply-emails doit supprimer l’en-tête In-Reply-To des messages de réponse, car ils auraient correctement rempli le tableau referenced_post_message_ids (« liste » ? Je suis nouveau en Ruby)
Cameron, merci d’avoir ouvert ce sujet à la discussion et d’avoir fourni beaucoup de détails dans vos publications. Je suis responsable de cette boîte de Pandore, issue de ces deux commits :
Nous sommes conscients de certains problèmes liés au threading dans les clients de messagerie tels que Thunderbird depuis un certain temps, mais cela ne représentait pas un grand nombre de consommateurs de threading par e-mail à partir de Discourse, donc cela a été repoussé. Mais maintenant que cela apparaît, nous devons passer du temps à réexaminer le problème et à travailler sur une solution.
Il est intéressant de noter que nous avons ajouté cet en-tête References au premier e-mail envoyé et à tous les suivants à l’époque, car cela permet au threading de fonctionner correctement dans Gmail, mais je suis d’accord que ce n’est pas idéal et que cela cause probablement les problèmes de threading, ainsi que le fait de ne pas utiliser le Message-ID original dans les en-têtes In-Reply-To et References des e-mails suivants.
Merci de votre patience pendant que j’examine les anciennes discussions et le code et que je travaille sur ce problème. En attendant, êtes-vous au courant d’autres clients de messagerie utilisés et qui rencontrent des problèmes ? Par exemple, je sais que c’est un problème dans Thunderbird, mais qu’en est-il des autres ? Merci.
Nous sommes désolés, mais votre message électronique à
["incoming+8349bd9eb1f2b582df4f32dbe85c3363@meta.discoursemail.com"]
(intitulé Re: [Discourse Meta] [bug] Les messages électroniques de Discourse sont
incorrectement classés par fil de discussion) n'a pas fonctionné.
Raison :
Désolé, les nouveaux utilisateurs ne peuvent mettre que 2 liens dans un message.
Si vous pouvez corriger le problème, veuillez réessayer.
Je vais la mettre sur le forum où je pourrai la rattraper et la réviser…
Cameron, merci d’avoir ouvert ce sujet à la discussion et d’avoir fourni
beaucoup de détails dans vos publications. Je suis responsable de cette boîte de Pandore,
à partir de ces deux commits :
3b13f1146b2a406238c50d6b45bc9aa721094f46
Cela semble correct. Est-ce que cela enregistre cet ID avec l’enregistrement de la base de données afin que les réponses entrantes puissent être liées au message de forum précédent ?
Voulez-vous également que je vérifie si le suffixe est syntaxiquement légal pour le RFC5322, en termes de caractères autorisés ?
82cb67e67b83c444f068fd6b3006d8396803454f
Ce second commit semble aborder un autre problème que nous avons rencontré : si un message provient d’un e-mail, le message-id sortant envoyé aux utilisateurs d’e-mail n’est pas le message-id du message source de l’auteur. Cela se traduit par deux messages distincts du point de vue d’un client de messagerie, et cela casse probablement les réponses faites à l’original par opposition à la copie envoyée par le forum. Par exemple :
À : le forum
CC : un des participants
Le participant recevra (eh bien, peut-être) une copie du forum et une copie directe de l’auteur, et ce seront des messages distincts de leur côté car ils auront des message-ids différents.
J’allais faire un second rapport de bug sur ce problème après avoir résolu le problème des en-têtes in-reply-to et references, qui est beaucoup plus important.
Nous sommes conscients de certains problèmes liés au chaînage depuis un certain temps dans les clients de messagerie tels que Thunderbird, mais cela ne représentait pas un grand nombre de consommateurs de chaînage d’e-mails de Discourse, donc cela a été repoussé, mais maintenant que cela apparaît, nous devons passer du temps à réexaminer le problème et à travailler sur une solution.
Je et plusieurs autres utilisons mutt. Je suis heureux de faire tout ce qui est nécessaire pour aider au débogage et à la revue de code. J’ai également été administrateur système de messagerie pendant des lustres dans mes vies antérieures.
[quote=“Cameron Simpson, post:1, topic:233499,
username:cameron-simpson”]
C’est le premier message. Il ne devrait pas avoir d’en-tête References, car il n’y a pas de message quelque part avec cet id.
[/quote]
Fait intéressant, nous avons ajouté cet en-tête References au premier e-mail envoyé et à tous les suivants depuis lors, car cela permet au chaînage de fonctionner correctement dans Gmail,
Je pense qu’un en-tête References correct (absent dans le premier message, comme in-reply-to dans les réponses) devrait également fonctionner. Mais GMail a une relation plutôt lâche avec les normes de messagerie parfois. J’ai un accord gmail ; je peux aussi faire du débogage là-bas. Et en principe, nous pouvons utiliser cette discussion même comme banc d’essai, peut-être.
mais je suis d’accord que ce n’est pas idéal et que cela cause probablement les problèmes de chaînage
ainsi que le fait de ne pas utiliser le Message-ID original dans les en-têtes In-Reply-To et References des e-mails suivants.
Merci de votre patience pendant que j’examine les anciennes discussions et le code et que je travaille sur ce problème.
Pas de souci.
En attendant, êtes-vous au courant d’autres clients de messagerie qui sont utilisés et qui rencontrent des problèmes ? Par exemple, je sais que c’est un problème dans Thunderbird, mais qu’en est-il des autres ? Merci.
Certainement mutt. Au moins avec mutt, il est très facile de voir les en-têtes et aussi de voir la chaîne de l’arbre de réponses, qui est souvent obscurcie dans d’autres clients.
Le chaînage de messages est entièrement défini par les en-têtes Message-ID et In-Reply-To. L’en-tête References a commencé avec USENET pour les suivis, et prenait en charge (là-bas) plusieurs message-ids ; le In-Reply-To n’en prend en charge qu’un seul. Il semble que References soit maintenant également présent dans RFC5322, et je vais vérifier sa sémantique.
Je suis juste en train de rassembler mes idées dans un grand article à ce sujet pour plus tard aujourd’hui, merci pour les informations supplémentaires jusqu’à présent !
D’accord, c’est assez énorme, merci de votre patience. Tout d’abord, merci pour une autre réponse détaillée et pour l’offre de débogage/révision, c’est vraiment utile J’ai en fait examiné cela ce matin et, étonnamment, le chaînage dans une vue unifiée fonctionne dans Thunderbird dans la plupart des cas, et je pense que l’en-tête References pointant constamment vers l’OP y contribue (par exemple, le sujet Reference dans cette chaîne qui est toujours présent est \u003ctopic/53@discoursehosted.martin-brennan.com\u003e.\n\n
\n\nLe cas où le chaînage ne fonctionne pas comme prévu est le suivant :\n\n1. Un message est créé dans Discourse et un e-mail est envoyé à ceux qui suivent le sujet puis\n2. Quelqu’un d’autre répond à ce message et un e-mail est envoyé à ceux qui suivent le sujet\n\nDans le cas du second e-mail, il reçoit un en-tête In-Reply-To et References incorrect car il en génère un sur cette ligne discourse/lib/email/sender.rb at 98bacbd2c6b9fe57167cd32af5eb4839b4a5d1f6 · discourse/discourse · GitHub plutôt que d’utiliser un en-tête existant. Il devrait utiliser le Message-ID de l’e-mail qui a été envoyé en premier. Dans la capture d’écran, c’est là que les messages suivant ce modèle devraient être placés :\n\n
\n\n\n\n[quote="Cameron Simpson, post:8, topic:233499, username:cameron-simpson"]\nCela semble correct. Cela enregistre-t-il cet identifiant avec l’enregistrement de la base de données afin que les réponses entrantes puissent être liées au message de forum précédent ?\n[/quote]\n\nLa réponse est – cela dépend. Si un message est créé dans Discourse à partir d’un e-mail entrant, comme celui-ci de votre part, nous utilisons le Message-ID entrant d’origine de ce message lorsque quelqu’un y répond pour les en-têtes In-Reply-To et References conformément à :\n\ndiscourse/lib/email/sender.rb at 98bacbd2c6b9fe57167cd32af5eb4839b4a5d1f6 · discourse/discourse · GitHub, nous utilisons simplement la référence de l’OP du sujet et générons une nouvelle référence, ce qui est évidemment ce qui cause tous les problèmes. Dans tous les cas, nous générons un nouveau Message-ID à chaque fois qu’un e-mail sortant est envoyé, ce qui semble correct et à la hauteur des autres clients de messagerie.\n\n[quote="Cameron Simpson, post:8, topic:233499, username:cameron-simpson"]\nCe deuxième commit semble résoudre un autre problème que nous avons rencontré : si un\nmessage provient d’un e-mail, le message sortant envoyé aux utilisateurs par e-mail n’est pas le message-id du message source de l’auteur. Cela entraîne\ndeux messages différents du point de vue d’un client de messagerie, et\ncasse probablement les réponses faites à l’original par opposition à la\ncopie envoyée par le forum.\n[/quote]\n\nJe pense comprendre ce que vous voulez dire, est-ce que cela se passe comme suit :\n\n1. cameron envoie un e-mail à Discourse depuis mutt, qui reçoit Message-ID: 74398756983476983@mail.com\n2. Discourse crée un message et stocke le Message-ID associé au message avec un enregistrement IncomingEmail\n3. johndoe suit le sujet, il reçoit donc un e-mail de Discourse avec un Message-ID: topic/222/44@discourse.com et aucune référence à l’Message-ID original : 74398756983476983@mail.com\n\nEst-ce que cela vous semble correct, que nous devrions simplement “transmettre” ce Message-ID à ceux qui suivent le sujet au lieu de générer le nôtre puisqu’il est déjà unique ? Que se passe-t-il alors dans le client de messagerie de johndoe si\ncameron l’a également mis en copie sur cet e-mail sortant original ? Cela semble être un problème distinct, il serait donc bon d’ouvrir un autre sujet de bug à ce sujet.\n\n[quote="Cameron Simpson, post:8, topic:233499, username:cameron-simpson"]\nPlusieurs d’entre nous utilisent mutt.\n[/quote]\n\nJe vais configurer un client mutt localement pour voir ce que vous voyez également, je n’ai jamais testé cette fonctionnalité dans un client textuel (uniquement Gmail et Thunderbird) donc je suis impatient de voir à quoi cela ressemble de toute façon.\n\n-----\n\nMa réflexion pour résoudre ces problèmes ce matin a été de supprimer les suffixes générés aléatoirement lorsque nous envoyons des en-têtes Message-ID dans les e-mails et de passer plutôt à un schéma où nous utilisons l’user_id de l’utilisateur expéditeur et du destinataire. L’avantage est qu’il n’est pas nécessaire de stocker le Message-ID n’importe où (sauf lorsqu’un e-mail entrant crée un message) et donc les en-têtes References et In-Reply-To seront toujours cohérents. Laissez-moi vous donner un exemple. Supposons que nous ayons ces utilisateurs :\n\n* martin - user_id 25\n* cameron - user_id 44\n* sam - user_id 78\n* bob - user_id 999\n\nEt puis nous avons ce sujet, topic_id 233499, avec des messages commençant par post_id 100 comme OP. Le format deviendrait topic/#{topic_id}/#{post_id}.s#{sender_user_id}r#{receiver_user_id}. L’ordre des opérations ressemblerait à ceci :\n\n1. martin crée l’OP\n * cameron reçoit un e-mail avec ces en-têtes :\n * Message-ID: topic/233499.s25r44@meta.discourse.org\n * References: topic/233499@meta.discourse.org\n * sam reçoit un e-mail avec ces en-têtes :\n * Message-ID: topic/233499.s25r78@meta.discourse.org\n * References: topic/233499@meta.discourse.org\n\n2. cameron répond par e-mail\n\n * discourse reçoit un e-mail avec ces en-têtes depuis mutt :\n * Message-ID: 43585349859734@test.com\n * References: topic/233499@meta.discourse.org topic/233499.s25r44@meta.discourse.org\n * In-Reply-To: topic/233499.s25r44@meta.discourse.org\n\n3. discourse (en tant que cameron, de l’e-mail ci-dessus) crée le message 101\n\n * sam reçoit un e-mail de Discourse avec ces en-têtes :\n * Message-ID: topic/233499/101.s44r78@meta.discourse.org\n * References: 43585349859734@test.com topic/233499@meta.discourse.org\n * In-Reply-To: 43585349859734@test.com\n\n2. sam répond par e-mail à cameron\n\n * discourse reçoit un e-mail avec ces en-têtes depuis gmail :\n * Message-ID: 5346564746574@gmail.com\n * References: topic/233499/101.s44r78@meta.discourse.org topic/233499@meta.discourse.org\n * In-Reply-To: topic/233499/101.s44r78@meta.discourse.org\n\n4. discourse (en tant que sam, de l’e-mail ci-dessus) crée le message 102\n\n * cameron reçoit un e-mail de Discourse avec ces en-têtes :\n * Message-ID: topic/233499/102.s78r44@meta.discourse.org\n * References: 5346564746574@gmail.com topic/233499@meta.discourse.org\n * In-Reply-To: 5346564746574@gmail.com\n\n5. bob crée le message 103 dans le sujet, pas en réponse à quelqu’un (notez que les References incluent ici le Message-ID envoyé aux deux utilisateurs pour l’e-mail OP)\n * cameron reçoit un e-mail avec ces en-têtes :\n * Message-ID: topic/233499/103.s999r44@meta.discourse.org\n * References: topic/233500@meta.discourse.org topic/23499.s25r44@meta.discourse.org\n * sam reçoit un e-mail avec ces en-têtes :\n * Message-ID: topic/233499/103.s999r78@meta.discourse.org\n * References: topic/233499@meta.discourse.org topic/23499.s25r78@meta.discourse.org\n\n6. cameron répond par e-mail\n\n * discourse reçoit un e-mail avec ces en-têtes depuis mutt :\n * Message-ID: 6759850728742572@test.com\n * References: topic/233499@meta.discourse.org topic/233499/103.s999r44@meta.discourse.org\n * In-Reply-To: topic/233499/103.s999r44@meta.discourse.org\n\nBoîte de réception de cameron\n\n* martin - OP du sujet\n * ENVOYÉ -\u003e à : discourse, RE : OP du sujet\n * sam - réponse au deuxième message\n * bob - réponse dans le sujet, pas à un message particulier\n * ENVOYÉ -\u003e à : discourse, RE : message de bob\n\nBoîte de réception de sam\n\n* martin - OP du sujet\n * cameron - deuxième message\n * ENVOYÉ -\u003e à : discourse, RE : deuxième message\n * bob - réponse dans le sujet, pas à un message particulier\n\nJe pense que c’est correct, pouvez-vous juste examiner ce que j’ai écrit dans ces en-têtes et vérifier si c’est ce que vous attendriez de ce scénario ? La seule chose dont je ne suis pas tout à fait sûr, c’est si j’ai couvert toutes les References, et bien sûr, je testerais cela sur un ensemble d’e-mails en direct dans une branche de développement avant de le déployer. Je n’ai pas encore testé quoi que ce soit dans mutt non plus.\n\n-----\n\nEn aparté, j’ai également examiné ce que GitHub fait avec ses e-mails de notification, et j’ai remarqué qu’ils font quelque chose de similaire où ils ont une Reference omniprésente (discourse/discourse/pull/252@github.com) qui est utilisée dans tous les e-mails liés à ce “sujet”, qui dans ce cas est une pull request GitHub :\n\n\nReferences: \u003cdiscourse/discourse/pull/252@github.com\u003e \u003cdiscourse/discourse/pull/252/issue_event/7042100517@github.com\u003e\nIn-Reply-To: \u003cdiscourse/discourse/pull/252/issue_event/7042100517@github.com\u003e\n
Par Martin Brennan via Discourse Meta le 22 juillet 2022 à 06:34 :
D’accord, c’est quelque chose d’énorme, veuillez me suivre. Tout d’abord, merci pour
une autre réponse détaillée et votre proposition de débogage / révision, c’est
vraiment utile Je me suis en fait penché sur ce sujet ce matin
et, étonnamment, le fil de discussion dans une vue unifiée fonctionne dans Thunderbird
pour la plupart des cas, et je pense que l’en-tête References pointant
systématiquement vers le message original (OP) y contribue (par exemple, le sujet Reference
dans cette chaîne, qui est toujours présent, est <topic/53@discoursehosted.martin-brennan.com>.
Je viens de relire attentivement la section 3.6.4 de la RFC 5322. Elle a évolué par
rapport aux versions antérieures (822 et 2822) et a fusionné les en-têtes de courriel In-Reply-To,
les en-têtes References d’USENET et les références modernes
répondant à plus d’un message précédent.
En résumé :
Le Message-ID est un identifiant unique et persistant pour un message.
In-Reply-To contient tous les identifiants de message auxquels ce message
répond directement. Ainsi, si je réponds à une paire de messages, il contiendra
ces 2 identifiants.
References est une chaîne de messages antérieurs, du message original au message
précédent. Il devrait donc toujours commencer par l’identifiant du message original.
Ainsi, pour des discussions comme celle-ci, en faisant semblant que les étiquettes sont des identifiants de message :
Il est également légal d’inclure “reply1 reply2” dans les références (l’autre
chaîne menant à reply5), mais la RFC recommande explicitement de ne pas le faire
parce que certains clients s’attendent à ce que les références forment une chaîne linéaire unique
de réponses, et non un graphe aplati.
Ma recommandation pour construire les références est donc d’utiliser les
références du message antérieur « principal » en y ajoutant l’identifiant du message
antérieur principal. De cette façon, vous obtenez toujours une chaîne linéaire dans le bon ordre.
Intéressant, il semble y avoir un certain fil de discussion là-bas.
Mais remarquez : le premier message a une petite flèche « est une réponse ». Même s’il
s’agit du message 1. Je suppose que c’est à cause de l’entrée « topic » dans les références,
ce qui amène TB à penser qu’il y avait un message antérieur (ce qui, bien sûr, n’était pas le cas).
Dans l’univers de mutt, nous ne voyons presque aucun fil de discussion :
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
C’est parce que l’en-tête In-Reply-To de chaque message pointe directement vers
le fictif identifiant de message « topic ». Mutt ignore probablement les References
parce qu’il s’agit d’un lecteur de courrier et que References provient à l’origine de USENET.
Peut-être que Thunderbird utilise les références ou enrichit l’en-tête In-Reply-To
avec des informations provenant des références.
Il suffit de consulter l’un des en-têtes In-Reply-To ou References pour gérer
les fils de discussion ; le premier provient du courrier électronique et le second d’USENET.
Vous prenez en charge les deux (ce qui est excellent !), nous devons donc les rendre
cohérents.
(Au passage : il y a aussi une discussion sur la mise en miroir USENET, car plusieurs
personnes du monde Python consomment les listes via une interface USENET. Là encore, un
sujet séparé.)
[…]
[quote=“Cameron Simpson, post:8, topic:233499,
username:cameron-simpson”]
Cela semble correct. Est-ce que cela enregistre cet identifiant avec l’enregistrement de la base de données afin que les réponses
entrantes puissent être liées au message antérieur du forum ?
[/quote]
La réponse est : cela dépend. Si un message est créé dans Discourse à partir d’un courriel entrant, comme celui-ci de votre part, nous utilisons l’identifiant de message Message-ID original de ce message entrant lorsque quelqu’un y répond, pour les en-têtes In-Reply-To et References comme suit :
Sinon, nous utilisons simplement la référence du message original du sujet et nous générons une nouvelle référence, ce qui est évidemment la cause de tous les problèmes. Dans tous les cas, nous générons un nouvel identifiant Message-ID à chaque fois qu’un courriel sortant est envoyé, ce qui semble correct et conforme aux autres clients de messagerie.
Hélas, pas tout à fait. Si vous êtes l’origine du message (c’est-à-dire rédigé dans
Discourse), générer l’identifiant de message ne pose pas de problème. S’il n’y a pas d’identifiant de message
(illicite), en générer un est une pratique standard (généralement par les MTA). Mais si
vous transmettez un message (rédigé dans un courriel), l’identifiant de message existant
devrait être préservé.
À mon avis, vous devez faire trois choses :
avoir un identifiant de message stable et ne pas remplacer l’identifiant de message d’un
message entrant
générer un In-Reply-To correct, qui se calcule facilement à partir du ou des
message(s) antérieur(s) immédiat(s), c’est-à-dire l’identifiant de message du/des antérieur(s)
générer des References corrects, qui se calculent facilement comme
références de l’antérieur + identifiant de message de l’antérieur
Pour le point 1, en examinant le code que vous citez, vous voudrez probablement que l’identifiant de
message du courriel soit (syntaxe Python, désolé) :
def message_id(post):
return post.incoming_email.message_id or discourse_message_id(post)
c’est-à-dire l’identifiant de message du courriel du message si celui-ci provient d’un courriel,
sinon l’identifiant de message de Discourse en utilisant un algorithme similaire à celui que
vous décrivez plus loin dans ce message : tout ce qui est (a) stable et (b)
syntaxiquement valide.
Ensuite, calculer les champs In-Reply-To et References est une question de
mécanique simple, comme aux points 2 et 3.
Je pense comprendre ce que vous voulez dire, est-ce que cela se passe comme ceci :
cameron envoie un courriel à Discourse depuis mutt qui obtient Message-ID: 74398756983476983@mail.com
Discourse crée un message et stocke l’identifiant Message-ID dans l’enregistrement IncomingEmail associé au message
C’est exact.
johndoe suit le sujet, il reçoit donc un courriel de Discourse avec un Message-ID: topic/222/44@discourse.com et aucune référence à l’identifiant Message-ID original 74398756983476983@mail.com
Non. Vous voulez vraiment transmettre IncomingEmail.message_id en tant que Message-ID dans le courriel destiné à johndoe. C’est le même message.
Est-ce que cela semble correct, que nous devrions simplement « transmettre » cet Message-ID à ceux qui suivent le sujet au lieu de générer le nôtre puisqu’il est déjà unique ? Que se passe-t-il alors dans le client de messagerie de johndoe si
cameron l’a également mis en copie carbone (CC) sur ce message sortant original ? Cela semble être un problème distinct, il serait donc bon d’ouvrir un autre sujet de bug à ce sujet.
En le transmettant, le message original (cameron->cc:johndoe) et le
message transféré par Discourse (cameron->Discourse->johndoe) ont le même
identifiant de message et le même contenu. Le système de messagerie récepteur
stocke les deux. Le lecteur de messagerie voit les deux et soit les présente tous les deux, soit
n’en conserve qu’un (c’est une décision politique du lecteur de messagerie - n’en conserver
qu’un est courant). Comme il s’agit du même message, en général, il n’importe
lequel est conservé.
Si nous ignorions Discourse et considérions un message qui était
une copie du message via la liste et aussi via un courriel direct. Ce sont
le même message, avec le même identifiant de message.
Je vais configurer un client mutt localement pour voir ce que vous voyez également. Je n’ai jamais testé cette fonctionnalité dans un client basé sur du texte (seulement Gmail et Thunderbird), donc je suis impatient de voir à quoi cela ressemble.
Heureux de vous aider avec les paramètres. Pour la vue filaire, vous devez définir le
critère de tri sur « threaded ». Mutt est très configurable.
Ma ligne de pensée pour résoudre ces problèmes ce matin était de me débarrasser
des suffixes générés aléatoirement lorsque nous envoyons les en-têtes Message-ID dans les courriels et de passer plutôt à un schéma où nous
utilisons l’user_id de l’utilisateur expéditeur et de l’utilisateur destinataire. L’avantage
de cela est qu’il n’est pas nécessaire de stocker l’Message-ID n’importe où
(sauf lorsqu’un courriel entrant crée un message) et donc les en-têtes References
et In-Reply-To seront toujours cohérents.
Oui, c’est beaucoup mieux. Notez que l’identifiant de message du courriel entrant
devrait remplacer l’identifiant de message dérivé de Discourse pour le courriel sortant.
(La plupart des systèmes de messagerie utilisent des chaînes aléatoires car il n’y a pas de contexte
entourant tel que la structure de message du sujet Discourse - les messages sont
considérés isolément ; mais la seule exigence réelle est l’unicité
persistante.)
Laissez-moi vous donner un exemple. Disons que nous avons ces utilisateurs :
martin - user_id 25
cameron - user_id 44
sam - user_id 78
bob - user_id 999
Et ensuite nous avons ce sujet, topic_id 233499, avec des messages commençant par post_id 100 en tant que message original. Le format deviendrait topic/#{topic_id}/#{post_id}.s#{sender_user_id}r#{receiver_user_id}.
Il ne devrait pas y avoir d’en-tête References dans le message original. Il n’est pas
nécessaire pour le fil de discussion et fait semblant qu’il existe un « message 0 »
qui n’existe pas. Cela signifie que chaque message original (a) ressemble à une réponse, ce qu’il
n’est pas, et (b) ressemble à la chose à laquelle il répond, qui est manquante
dans la boîte aux lettres du lecteur.
Cela crée des identifiants de message différents pour chaque copie sortante du message original.
C’est mauvais. Ils doivent être identiques. Supposons que sam mette cameron en copie carbone
directement dans une réponse. Le In-Reply-To citera un identifiant de message que cameron
n’a jamais reçu.
Vous pouvez simplement supprimersender_user_id et receiver_user_id du
champ d’identifiant de message et obtenir un identifiant unique que chaque destinataire voit.
La contrainte d’unicité est le message lui-même, et non l’objet
« message » individuel au niveau du courriel.
Concernant les References, le message original ne devrait pas en avoir. TB et tout le reste
iront bien. S’ils filent en utilisant References au lieu de In-Reply-To, les References dans les messages de réponse suffisent.
Voici le début d’un fil de discussion de liste de diffusion dans 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
Ignorez le fait que je trie mes courriels du plus récent au plus ancien. Remarquez qu’il n’y a pas de flèche sur
le message initial (en bas). Ce message n’a ni References ni In-Reply-To. Tous les autres ont In-Reply-To (et peut-être References, mais il s’agit d’une liste de diffusion par courriel, donc pas nécessairement ; comme je
l’ai mentionné précédemment, ils sont complémentaires).
Si je répète mon exemple Discourse d’auparavant :
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
Voyez qu’ils ont tous une flèche de début ? C’est parce que le client de messagerie
pense qu’ils sont tous des réponses à un message racine commun (et manquant),
ce qui est dû à l’identifiant de message « topic » dans l’en-tête References.
Alors que le message 1 est en fait le message du bas affiché ci-dessus.
Résumé :
votre plan est bon, à condition de supprimer l’expéditeur et le destinataire de l’
identifiant de message - ils sont inutiles et en fait le destinataire causera
des problèmes (l’expéditeur est simplement redondant).
supprimez le pseudo-identifiant de message « topic » des References - il induit en erreur
les clients de messagerie (y compris TB, même si ce n’est pas visuellement évident)
cameron répond par courriel
discourse reçoit un courriel avec ces en-têtes depuis mutt :
Oui, encore une fois avec la réserve qu’il ne devrait pas y avoir de référence « topic ».
Comme prévu, il y a une référence à l’identifiant de message du message original. Bien qu’il devrait
être le même identifiant de message que sam voit pour le message original.
discourse (en tant que cameron, à partir du courriel ci-dessus) crée le message 101
sam reçoit un courriel de discourse avec ces en-têtes :
Et là, ça coince. Le Message-ID devrait être 43585349859734@test.com provenant du champ .incoming_post.message_id.
(Bon, à mon avis, c’est post.message_id(), qui renvoie post.incoming_post.message_id pour un message généré par courriel et le vôtre
généré par Discourse sinon).
Considérez ceci : je compose et envoie ma réponse avec l’identifiant de message 43585349859734@test.com. Pour des raisons de continuité, je garde une copie de cela
dans mon dossier local, où elle apparaît comme une réponse au message original. Idéalement,
Discourse m’envoie également une copie de mon propre message (c’est un paramètre de politique
sur de nombreuses listes de diffusion), donc je reçois aussi la version de Discourse. Cela devrait
avoir le même identifiant de message, car il s’agit du même message, juste par un
chemin différent.
Le message de Discourse n’est pas « en réponse à » mon message. Il est mon
message, simplement transféré.
Cet effet se répercute dans vos exemples suivants. Le processus réel
devrait être plus simple que ce que vous en avez fait.
Pensez-y ainsi. Si je réponds à un message depuis un courriel, c’est effectivement comme
si j’envoyais un courriel à sam (et aux autres) via Discourse. Discourse
transfère mon message aux abonnés recevant par courriel, et
« incidemment » garde une copie sur le forum
À titre d’information, j’ai également examiné ce que fait GitHub avec ses
courriels de notification, et j’ai remarqué qu’ils font quelque chose de similaire où ils
ont une Reference toujours présente
(discourse/discourse/pull/252@github.com) qui est utilisée dans tous les
courriels liés à ce « sujet », qui est dans ce cas une demande de tirage (pull request) GitHub :
Hoo, GitHub. Quel désastre que leurs courriels de problème
Cependant, dans leur scénario, la PR est le message original. Donc une référence directe
à la demande de tirage est sensée. Vous pourriez utiliser l’identifiant de message « topic » pour le message 1,
à condition de ne pas utiliser aussi l’identifiant « topic/1 ». Mais il semble y avoir
peu d’intérêt - c’est un effort supplémentaire pour traiter le cas particulier du message 1 - je
utiliserais simplement « topic/1 » moi-même.
Pour ajouter une complication. À ma connaissance, un administrateur peut déplacer un message
ou un sujet. Cela ne brise-t-il pas le schéma « générer l’identifiant de message »,
particulièrement s’ils ne déplacent qu’un message ? Je suis plutôt d’avis que
tout message devrait avoir un champ _message_id, rempli à partir du
message entrant (depuis un courriel) ou généré (publication via Discourse). Ensuite,
il est persistant, stable et robuste face à tout remaniement de messages ou
changement d’algorithme.
Enfin, il y a une petite considération de sécurité : vous devez ignorer l’
identifiant de message du courriel entrant (et éventuellement rejeter le message) s’il
revendique l’identifiant de message d’un message existant. Puisque, en tant qu’auteur, je peux mettre
n’importe quoi dans cet en-tête Je choisirais simplement de supprimer l’
identifiant de message - accepter le message, mais ne pas le laisser prétendre être un autre
message - donner à votre copie l’identifiant généré par Discourse, puis procéder
normalement.
Merci encore pour cette réponse merveilleusement détaillée. Il me faudra probablement un peu de temps pour assimiler tout cela et en faire des actions concrètes, alors soyez patients avec nous (en plus de cela, j’ai d’autres projets internes prioritaires sur lesquels je travaille actuellement). Je pense qu’avec ces informations, nous serons en mesure de rendre nos systèmes de threading beaucoup plus robustes et conformes aux spécifications. Je pourrais avoir d’autres questions en parcourant votre message, merci Cameron.
Par Martin Brennan via Discourse Meta le 25Juillet2022 00:28 :
Wow, merci encore pour cette réponse incroyablement détaillée. Il me faudra probablement un peu de temps pour assimiler cela et le transformer en actions concrètes, alors soyez patients avec nous (en plus de cela, j’ai d’autres projets internes de haute priorité sur lesquels je travaille actuellement). Je pense qu’avec ces informations, nous pourrons rendre nos systèmes de discussion beaucoup plus robustes et conformes aux spécifications. Je pourrais avoir d’autres questions en parcourant votre publication, merci Cameron.
C’est-à-dire qu’il a préservé mon message-id d’e-mail d’origine. Donc, le In-Reply-To est correct, et le References contient au moins mon message-id d’e-mail.
Ah, c’est une observation intéressante, je n’avais pas remarqué la petite flèche.
C’est aussi super intéressant. Je crois (sans examiner le code source) que Thunderbird fait cela, et probablement l’interface Gmail aussi, puisqu’elle fait la même chose.
Nous semblons faire cela, mais je suppose que ce n’est pas constant ? Essentiellement, nous devons nous assurer que :
TODO #1 - Si un message a un enregistrement IncomingEmail associé, nous utilisons toujours cet identifiant de message lors de l’envoi d’e-mails.
TODO #2 - Ne pas utiliser de References lors de l’envoi d’e-mails liés à l’OP du sujet.@cameron-simpson une question cependant – si l’OP a été créé via un e-mail entrant, utiliserions-nous cet Message-ID dans References pour l’OP ou l’exclurions-nous toujours ?
C’est intéressant, je pensais que chaque destinataire de l’e-mail devait avoir un Message-ID unique ? En fait, je crois que c’est pour cela que nous avons choisi d’ajouter l’unicité à l’Message-ID de chaque destinataire, pour éviter les comportements de spam, en repensant à notre sujet interne. Peut-être que @supermathie, qui fait partie de notre équipe d’infrastructure et qui a effectué de nombreux tests avec l’e-mail plus tôt cette année, pourrait également donner son avis ici ?
Ce que vous dites, c’est que c’est plutôt le message qui détermine un Message-ID unique pour tous les destinataires. Alors peut-être que nous en générons simplement un pour chaque message qui génère un e-mail ? Ensuite, nous pourrions également déplacer l’IncomingEmail.message_id ici. Tentativement, le changement que nous devrions apporter est :
TODO #3 - Ajouter un outbound_message_id à la table Post. Le générer une fois lorsqu’un e-mail est envoyé pour la première fois en relation avec le message. L’utiliser pour les en-têtes References et In-Reply-To ultérieurs. Définir sa valeur lorsqu’un message est créé à partir d’un IncomingEmail. Le format devrait être topic/:topic_id/:post_id/:random_alphanumeric_string@host par exemple topic/233499/33545/gvy8475y7c45y87554c@meta.discourse.org
Après ce changement, mon premier exemple deviendrait ceci :
Avec la considération supplémentaire que l’OP n’a pas de traitement spécial, il ne sera plus au format topic/:topic_id@hostname.
TODO #4 - S’assurer que les en-têtes In-Reply-To et References corrects sont générés en fonction des enregistrements PostReply et de la nouvelle colonne outbound_message_id dans la table Post
Je pense que nous en tenons compte, je vais vérifier.
Cela semble certainement être le cas
Pouvez-vous confirmer que les TODOs ici semblent raisonnables, Cameron ? Cela ne semble vraiment pas grand-chose maintenant que j’y regarde. Je me demande aussi, quand j’aborderai ce travail, seriez-vous ouvert à me rejoindre sur une instance Discourse de test sur laquelle les modifications WIP seraient déployées afin que nous puissions nous envoyer des e-mails et tester que les choses fonctionnent correctement ? Je ferai bien sûr mes propres tests avant de vous impliquer.
Sinon, ce n’est pas grave non plus – j’ai Thunderbird et je vais installer mutt et je pourrai tout tester là-bas
@cameron-simpson une chose que je voulais clarifier ici est la portée de « message_id ».
La chose qui a déclenché toute cette danse était un fort soupçon de la part de @supermathie que nos message_ids non uniques causaient des problèmes.
Discourse génère des e-mails uniques par utilisateur pour chaque e-mail qu’il envoie. Donc, par exemple, disons que 2 utilisateurs regardent ce sujet :
L’utilisateur 1 reçoit la charge utile 1 avec un lien de désabonnement distinct destiné à l’utilisateur 1
L’utilisateur 2 reçoit la charge utile 2 avec un lien de désabonnement distinct destiné à l’utilisateur 2
Si dans les deux cas notre identifiant de message était, disons, discourse_topic_100/23 (topic_id/post_number), alors nous dirions aux MTA que discourse_topic_100/23 peut avoir 2 charges utiles distinctes. L’hypothèse est qu’ils traitent cela comme un signal de spam.
Hé Discourse… vous venez d’envoyer deux e-mails appelés discourse_topic_100/23, qu’est-ce qui se passe ?
Étant donné que Discourse contrôle tout le transport des e-mails et que les e-mails ne sont pas ajoutés à une liste Cci ou Cci comme les listes de diffusion traditionnelles, nous pouvons nous permettre d’avoir des liens de désabonnement propres par utilisateur.
Qu’en pensez-vous ? Que pensez-vous du simple changement d’utiliser discourse_topic_100/23/7333 par exemple (topic_id, post_number, user_id) comme identifiant unique pour le courrier, c’est certainement une charge utile unique et nous pouvons facilement y faire référence lors de la génération d’e-mails pour un utilisateur.
Par Martin Brennan via Discourse Meta le 26 juillet 2022 à 00:27 :
C’est également très intéressant. Je crois (sans examiner le code source) que Thunderbird le fait, et probablement l’interface utilisateur de Gmail aussi, puisqu’elle fait la même chose.
Je pense que Mutt utilisera les deux, mais probablement uniquement In-Reply-To s’il est présent, en renvoyant à References en cas d’absence. Je devrais vérifier le code source.
Avec References, vous connaissez au moins toute la chaîne jusqu’au message original (OP) ; avec In-Reply-To, vous avez plus ou moins besoin des messages antérieurs environnants pour reconstituer le fil. Pour les listes de diffusion, je conserve généralement tout le fil localement jusqu’à ce qu’il soit terminé, et je suppose que c’est courant.
Il semble que nous fassions cela, mais je suppose pas de manière cohérente ? Fondamentalement, nous devons nous assurer que :
TODO #1 - Si un message a un enregistrement IncomingEmail associé, nous utilisons toujours cet identifiant de message (Message-ID) lors de l’envoi du courrier électronique.
Oui. C’est pourquoi je pensais qu’il serait plus logique d’avoir un champ explicite pour l’identifiant de message, à remplir une seule fois. Ensuite, l’utiliser systématiquement par la suite, quelles que soient les modifications apportées au processus de génération de l’identifiant de message dans le code ultérieurement.
TODO #2 - Ne pas utiliser References lors de l’envoi de courriers électroniques liés au message original (OP) du sujet.
Oui. Le message original n’a pas d’antécédent, donc il n’y a ni References ni In-Reply-To.
@cameron-simpson une question toutefois – si le message original a été créé via un courrier électronique entrant, utiliserions-nous cet Message-ID dans References pour le message original ou l’exclurions-nous toujours ?
Toujours l’exclure. Mais l’utiliser comme identifiant de message persistant pour le message original.
Ainsi, un message rédigé par courrier électronique (message original ou réponse) tire son identifiant de message du courrier. Celui rédigé sur le web en reçoit un lorsque l’utilisateur clique sur Envoyer, généré par Discourse. Dès lors, c’est cet identifiant qui est utilisé, quelle que soit sa méthode de création.
C’est intéressant, je pensais que chaque destinataire du courrier électronique devait avoir un Message-ID unique ?
Non. L’identifiant de message identifie le « message », et non la copie individuelle. Je peux poster sur le forum et mettre quelqu’un en copie directe. Si cette personne reçoit une copie directement de moi et aussi via le forum, elle devrait avoir le même identifiant de message.
En fait, je crois que c’est pourquoi nous avons opté pour l’ajout d’unicité à l’identifiant de message de chaque destinataire, afin d’éviter les comportements de spam, en regardant en arrière notre sujet interne. Peut-être que @supermathie, qui fait partie de notre équipe d’infrastructure et a effectué de nombreux tests avec le courrier électronique plus tôt dans l’année, pourrait aussi donner son avis ici ?
Peut-être. Mais à première vue, le fil de discussion est en effet brisé. Certes, l’envoi du même message à plusieurs personnes devrait avoir le même identifiant de message, et généralement, en tant que transmetteur (courrier électronique → Discourse → destinataires du courrier électronique), Discourse ne devrait pas modifier les identifiants de message.
Ce que vous dites, c’est que c’est plutôt le message qui devrait déterminer un seul Message-ID pour tous les destinataires. Alors, peut-être devrions-nous simplement en générer un pour chaque message qui génère un courrier électronique ?
Chaque message devrait avoir un identifiant de message unique et stable pour son utilisation du côté du courrier électronique. Si le message provient d’un courrier électronique, cet identifiant de message original doit être utilisé. Sinon (via l’interface web), Discourse devrait générer un identifiant de message et le stocker avec le message.
Ensuite, nous pourrions également déplacer IncomingEmail.message_id ici aussi.
Bien sûr. Avoir un ensemble distinct de champs (l’identifiant de message semble suffisant) contenant l’état du côté du courrier électronique devrait suffire.
À titre provisoire, la modification que nous devrions apporter est :
TODO #3 - Ajouter un outbound_message_id à la table Post. Le générer une seule fois lorsqu’un courrier électronique est envoyé pour la première fois en relation avec le message.
Si vous avez reçu le message par courrier électronique, vous devez utiliser celui-ci, et non en générer un nouveau.
L’utiliser pour les en-têtes References et In-Reply-To subséquents. Définir sa valeur lorsqu’un message est créé à partir d’un IncomingEmail.
Oui. À l’identifiant de message du courrier électronique.
Le format doit être topic/:topic_id/:post_id/:random_alphanumeric_string@host par exemple topic/233499/33545/gvy8475y7c45y87554c@meta.discourse.org
Pour ceux que vous générez vous-mêmes, cela me semble bon.
Après cette modification, mon premier exemple deviendrait ceci :
martin crée le message original
cameron reçoit un courrier électronique avec ces en-têtes :
Mais notez : l’identifiant de message doit seulement être stable et unique. Si topic/:topic_id/:post_id@host est stable et ne sera jamais régénéré, cela suffira. Mais si vous vous inquiétez de cela (par exemple, restaurations de base de données, migrations ou importations apportant ces mêmes numéros), alors la chaîne aléatoire le rendra robuste contre les collisions.
Notez que la partie gauche de l’identifiant de message est un dot-atom-text, défini ici :
qui comprend des lettres, des chiffres et un ensemble limité de caractères de ponctuation (qui inclut « / »).
Notez les chevrons. L’identifiant de message est formellement la partie entre les chevrons, et les chevrons sont obligatoires. Syntaxe ici :
En considérant également que le message original ne bénéficie pas de traitement spécial, il ne sera plus au format topic/:topic_id@hostname.
Ça semble bien.
TODO #4 - Veiller à ce que les en-têtes In-Reply-To et References corrects soient générés en fonction des enregistrements PostReply et de la nouvelle colonne outbound_message_id de la table Post
Merci.
Je pense que nous avons déjà une considération à ce sujet, je vais vérifier.
+1
Cela semble certainement être le cas
Pouvez-vous confirmer que les TODOs ici semblent raisonnables, Cameron ?
Ils me semblent corrects.
Cela ne semble vraiment pas grand-chose maintenant que j’y regarde. Je me demande aussi, quand j’arriverai à ce travail, seriez-vous ouvert à rejoindre une instance de test de Discourse avec moi, sur laquelle les modifications en cours de développement (WIP) seront déployées, afin que nous puissions nous envoyer des courriers électroniques et tester que tout fonctionne correctement ? Je ferai bien sûr mes propres tests avant de vous impliquer.
Bien sûr. Heureux d’aider de quelque manière que ce soit.
Sinon, ce n’est pas grave non plus – j’ai Thunderbird et je vais configurer mutt, et je pourrai tout tester là-bas
Je peux vous aider avec mutt si vous le souhaitez aussi.
Je pense que vous pouvez toujours envoyer des messages distincts avec le même message-id, même avec de petites différences comme celle-ci.
Les listes de diffusion ordinaires font cela tout le temps à un degré ou à un autre. Au moins, certaines manipulations d’en-tête se produisent toujours. Mais le corps du message est aussi parfois modifié. Un exemple flagrant est python-list, qui rejette les pièces jointes non textuelles. Le message passe avec le même message-id cependant. Et presque toutes les listes ajoutent une note en bas avec, par exemple, un lien vers la page d’administration de la liste ou un lien de désabonnement. Cela n’aura pas été sur le message lorsqu’il est arrivé.
Et il y a eu de longues discussions sur la signature de contenu qui tournent autour de ce qui devrait être couvert par une signature.
Je serais donc tout à fait d’accord pour que vous ajoutiez votre lien de désabonnement spécifique au destinataire et que vous conserviez le message-id d’origine. Les avantages l’emportent largementlargement sur la perte de la mise en fil d’Ariane si vous donniez à chaque copie de message un message-id individuel.
Encore une fois, considérez l’utilisateur de messagerie. Je peux répondre à un message de discourse et ajouter un CC à une personne extérieure intéressée. Peut-être qu’elle reçoit une copie de discourse, peut-être pas. Mais si c’était le cas, elle devrait avoir le message-id source dessus même avec votre note supplémentaire. Sinon, elle aura 2 copies de mon message, mais son système de messagerie ne saura pas qu’il s’agit de copies du même message. Des problèmes s’ensuivent.
Donc, en bref : je ne pense pas que votre très petit texte de désabonnement supplémentaire justifie des message-ids distincts. Gardez-en un seul.
Désolé, je rattrape mon retard, voici quelques réflexions, dont certaines ont déjà été abordées…
La difficulté ici est que ce qui est envoyé depuis Discourse est un message différent de celui entrant. Il a des métadonnées différentes (à cet effet, À/De/Répondre à/Se désabonner/etc.) et un corps différent (il est personnalisé par utilisateur (je pense ? Est-ce que cela n’arrive pas en mode liste de diffusion ?)).
Quel est exactement le message ? En considérant 5322 comme parole d’évangile :
Un message se compose de champs d’en-tête, éventuellement suivis d’un corps de message.
Le champ “Message-ID:” fournit un identifiant de message unique qui fait référence à une version particulière d’un message particulier.
[emphase ajoutée]
C’est cette « version particulière » qui me fait penser qu’il serait inapproprié de renvoyer un message entrant avec un Message-ID différent. Cependant, si vous changez votre point de vue de Discourse en tant que « logiciel de forum » à Discourse en tant que « logiciel de liste de diffusion », alors cela a un peu de sens, donc je comprends votre point de vue. 5322 dit aussi :
Il existe de nombreux cas où les messages sont « modifiés », mais ces modifications ne
constituent pas une nouvelle instantiation de ce message, et par conséquent le message
ne recevrait pas un nouvel identifiant de message. Par exemple, lorsque les messages sont
introduits dans le système de transport, ils sont souvent précédés de
champs d’en-tête supplémentaires tels que des champs de trace (décrits dans la section 3.6.7)
et des champs renvoyés (décrits dans la section 3.6.6). L’ajout de tels champs d’en-tête
ne modifie pas l’identité du message et par conséquent l’original
champ “Message-ID:” est conservé. Dans tous les cas, c’est le sens que le
l’expéditeur du message souhaite transmettre (c’est-à-dire, s’il s’agit du même
message ou d’un message différent) qui détermine si le
champ “Message-ID:” change, et non une différence syntaxique particulière qui
apparaît (ou n’apparaît pas) dans le message.
Je suppose que cela se résume à la question : l’expéditeur du message change-t-il lorsque Discourse l’envoie ?
Peut-être devrions-nous utiliser Resent-Message-ID et ses amis ?
Il a toujours été là, depuis 822. Mais comme vous le dites plus tard, oui, il a été mis à jour.
5322 parle également directement de la manière dont Discourse et Github l’utilisent :
Le champ “In-Reply-To:” peut être utilisé pour identifier le message (ou les messages) auquel
le nouveau message répond, tandis que le champ “References:” peut être utilisé pour
identifier un “fil de discussion” de conversation.
Probablement de manière légèrement incorrecte, probablement en raison de l’absence d’un en-tête “Thread Identifier” approprié. Mais cette interprétation n’est peut-être pas ce que les auteurs de la RFC avaient l’intention… elle ne traite pas les messages avec des “References” mais sans “In-Reply-To”.
Le point délicat ici est que nous n’envoyons pas un e-mail, nous en envoyons N - un par destinataire - afin que leurs métadonnées individuelles (Désabonnement, etc.) puissent être correctes.
Et oui, j’ai vu des indications fortes lors des tests que la détermination du spam serait liée à un Message-ID. S’il était revu plus tard (même utilisateur ou utilisateur différent), il serait beaucoup plus susceptible d’être marqué comme spam.
Les avantages ici, pour être honnête, concernent entièrement le suivi correct des e-mails dans certains clients de messagerie, au détriment de la délivrabilité.
L’actuel topic/#{topic_id}/#{post_id}.s#{sender_user_id}r#{receiver_user_id} le rend au moins cohérent pour un utilisateur dans sa boîte aux lettres. L’hypothèse
Ma plus grande préoccupation est la délivrabilité - il est déjà assez difficile de faire livrer les e-mails lorsqu’il n’y a aucune visibilité de la part des principaux fournisseurs.
Mais je vois un argument fort pour que Discourse se comporte davantage comme un logiciel de liste de diffusion en mode liste de diffusion. @martin Je crois que nous ne personnalisons pas le corps du message en mode liste de diffusion ? Pensez-vous qu’il soit logique d’adopter une approche plus stricte concernant la conservation et la réutilisation des Message-IDs en mode liste de diffusion ?
Je ne veux pas me retrouver dans une situation où le parfait est l’ennemi du suffisamment bon.
Nous utilisons maintenant un « suffixe aléatoire » dans les messages et cela cause sans aucun doute des problèmes.
Nous avons 3 options sur la table :
Identifiants de message aléatoires impossibles à référencer
Identifiants de message stables par sujet/publication/utilisateur
Identifiants de message stables par paire sujet/publication
Nous sommes actuellement dans la situation (1) qui cause des ravages.
Je crains que nous ne tombions dans une paralysie décisionnelle entre (2) et (3).
Peut-être devrions-nous simplement commencer par (2) en reconnaissant que l’ajout de Ccs supplémentaires à un e-mail de Discourse peut entraîner un comportement inattendu, et au moins arrêter la majorité des problèmes ici ?
ah ! Je pensais que nous faisions déjà : topic/#{topic_id}/#{post_id}.s#{sender_user_id}r#{receiver_user_id}
Je serais enclin à, dans l’intérêt d’équilibrer les préoccupations d’unicité et de délivrabilité des e-mails par rapport à celles du mode liste de diffusion, faire \(2) pour le mode liste de diffusion désactivé et (3) pour le mode liste de diffusion activé.
De même, avec l’en-tête References, je serais enclin à ce qu’il soit absent pour le message n°1 d’un sujet et qu’il référence le sujet (donc topic/#{topic_id}) et le message auquel il répond, le cas échéant.
J’ai en fait examiné cela ce matin et, étonnamment, le chaînage dans une vue unifiée fonctionne dans Thunderbird dans la plupart des cas, et je pense que l’en-tête 
\n\n[quote="Cameron Simpson, post:8, topic:233499, username:cameron-simpson"]\nCela semble correct. Cela enregistre-t-il cet identifiant avec l’enregistrement de la base de données afin que les réponses entrantes puissent être liées au message de forum précédent ?\n[/quote]\n\nLa réponse est – cela dépend. Si un message est créé dans Discourse à partir d’un e-mail entrant, comme 
