Les messages électroniques de Discourse sont mal classés par ordre chronologique

Bug
26

Mes excuses à l’avance pour le ton de ce qui suit. J’ai l’air exaspéré, car je le suis un peu.

Par Michael Brown via Discourse Meta le 27 juillet 2022 à 14:06 :

Désolé, je rattrape mon retard maintenant, 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 qui est reçu. Il a des métadonnées différentes (à cette fin, À/De/Répondre à/Se désabonner/etc.) et un corps différent (il est personnalisé par utilisateur (je pense ? Cela n’arrive-t-il pas en mode liste de diffusion ?)).

Qu’est-ce que c’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 de ma part]

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.

Eh bien, malheureusement, cela dépend d’une lecture trop littérale, peut-être d’une lecture d’un contexte qui n’est pas là.

Chaque message électronique voit ses en-têtes modifiés au fur et à mesure que le système de messagerie le transmet. Sinon, des en-têtes Received: sont ajoutés à chaque étape, et plusieurs systèmes ajoutent divers en-têtes indiquant les résultats du filtrage anti-spam et les signatures. Rien de tout cela ne déclenche une modification du message-id, et en fait, le faire rendrait le message-id totalement dysfonctionnel.

Concernant le contenu, comme mentionné précédemment, presque toutes les listes de diffusion ajoutent du contenu au corps du texte, généralement un pied de page avec un lien vers la page d’administration de la liste ou un lien de désabonnement. Là non plus, cela ne déclenche pas de changement de message-id.

En fait, presque rien qui transfère un message ne change le message-id. Parce que cela casserait le suivi des conversations et la détection des doublons pour les clients utilisateurs finaux.

Je vois que vous continuez à citer ce que j’étais sur le point de citer :slight_smile:

5322 dit aussi :

Il y a 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, le champ “Message-ID:” original est conservé. Dans tous les cas, c’est le sens que 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 ou non, 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 ?

Je pense que vous avez mal lu les choses ici. Laissez-moi souligner :

Dans tous les cas, c’est le sens que 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

L’expéditeur est l’auteur, pas un MTA tel que Discourse.

Si j’envoie un message à Discourse par e-mail, je veux que mon message atteigne les lecteurs tel quel, sémantiquement parlant. Les éventuels ajouts comme les liens de désabonnement ne changent pas la sémantique de ce que j’ai dit dans mon message.

C’est toujours le même message.

Peut-être devrions-nous utiliser Resent-Message-ID et ses amis ?

Absolument pas. Ils sont destinés à un utilisateur qui renvoie un message. Par exemple, si je transférais un message à quelqu’un d’autre. Ils ne sont pas destinés aux relais de messagerie (comme les listes et Discourse).

Il a toujours été là, depuis 822. Mais comme vous le dites plus tard, oui, il a été mis à jour.

Aïe. Je pensais que c’était uniquement USENET à ce moment-là. Je me rétracte.

5322 parle aussi directement de la façon dont Discourse et Github l’utilisent :

Le champ “In-Reply-To:” peut être utilisé pour identifier le (ou les) message(s) auquel le nouveau message est une réponse, tandis que le champ “References:” peut être utilisé pour identifier un “fil de discussion” de conversation.

Peut-être un peu incorrectement, 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 une “Références” mais sans “In-Reply-To”.

Cela me dit que les deux champs couvrent la même information :

  • References montre un fil linéaire (généralement) jusqu’à l’OP
  • In-Reply-To montre le parent, et implique le même fil dans l’ensemble avec les messages précédents jusqu’à l’OP

La partie délicate est que nous n’envoyons pas un e-mail, nous en envoyons N - un par destinataire - afin que leurs métadonnées individuelles (Se désabonner, etc.) soient correctes.

Ce n’est pas délicat. Le sens des messages est le même, les personnalisations sont mineures et sémantiquement non pertinentes. Elles ne justifient pas de nouveaux identifiants de message distincts.

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.

Pouvez-vous montrer certains de ces exemples ? Parce que les message-ids permettent la déduplication à la fin de l’utilisateur. Et gardez à l’esprit que de nombreuses mesures “anti-spam” sont des ordures malavisées. Le nombre de choses que j’ai vues rejetées comme spam potentiel pour des raisons totalement fallacieuses… casser l’e-mail pour contourner un mauvais filtrage anti-spam est un mauvais choix.

À ce jour, je ne mets jamais en copie des personnes ayant des adresses GMail car le filtrage anti-spam de GMail me connaît et laisse tomber des choses. Si j’envoie uniquement à la liste, ils le reçoivent. Si je mets en copie leur adresse GMail, cela (a) le marque comme spam et (b) marque ensuite aussi le message de la liste de diffusion comme spam (même message-id !) L’utilisateur final ne voit pas mon message. Cette logique est totalement fallacieuse et irréparable.

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é.

Soupir. Pour tous les clients de messagerie. Et une raison majeure pour laquelle les gens de Python disent qu’ils n’utiliseront pas Discourse est que le suivi des e-mails est cassé. Beaucoup de gens n’utilisent pas de forums, car chaque forum exige qu’ils le visitent. Les e-mails leur parviennent, ils peuvent utiliser leur lecteur préféré et leur éditeur préféré, et le suivi permet aux gens de voir clairement le déroulement de la discussion. Quand ça marche.

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 sans aucune visibilité de la part des principaux fournisseurs.

J’aimerais voir des preuves. Les listes de diffusion font cela correctement partout dans le monde. Discourse le casse définitivement et objectivement. J’essaie de le faire réparer.

Permettez-moi de réitérer les deux problèmes fondamentaux ici :

  • L’OP In-Reply-To et References citent un “message-id de” “topic” fictif “pré-OP”, donc aucun utilisateur de messagerie n’a un fil de discussion avec un message de départ (l’OP) - tout, y compris l’OP, ressemble à un suivi.
  • Les e-mails reçus via Discourse et les e-mails reçus directement par exemple via CC ont des message-ids différents bien qu’ils soient sémantiquement le même message ; cela casse le suivi et la déduplication.

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 judicieux d’adopter une approche plus stricte concernant la préservation et la réutilisation des Message-IDs en mode liste de diffusion ?

Il y a des gens chez les Pythonistes qui ont trouvé le “mode liste de diffusion” trop “feu de paille”. Ils veulent recevoir des e-mails pour des sujets ciblés, mais pas pour tout. La gestion des message-ids devrait être la même pour tout le côté e-mail.

Je suis une personne du type “mode liste de diffusion” sur discuss.python.org. Mais je l’ai activé ici (discourse.org) et je l’ai _immédiatement désactivé à nouveau. J’ai besoin d’un mode ciblé ici.

4 « J'aime »
27

Par Michael Brown via Discourse Meta le 27juil2022 22:37 :

ah ! Je pensais que nous faisions déjà : topic/#{topic_id}/#{post_id}.s#{sender_user_id}r#{receiver_user_id}

{receiver_user_id} vous place dans des identifiants de message distincts par utilisateur final pour le même message source. C’est mauvais dès que les utilisateurs finaux communiquent en dehors de Discourse ou reçoivent des copies non via Discourse.

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é.

Et comme mentionné dans mon récent post, le mode liste de diffusion ne couvre qu’une seule saveur de réception d’e-mails Discourse. Toutes les mêmes préoccupations s’appliquent que le destinataire de l’e-mail soit en mode liste de diffusion ou simplement en mode e-mail pour certains sujets/tags.

De même, avec l’en-tête References, je serais enclin à le faire absent pour le post n°1 d’un sujet

De même pour In-Reply-To. aucun des deux ne devrait être présent, car pour être présent, ils doivent faire référence à un message fictif par-à-OP.

et à le faire référencer le sujet (donc topic/#{topic_id}) et le post

auquel il répond, le cas échéant.

Vous ne pouvez pas faire référence à l’identifiant de message du “sujet” à moins qu’il n’y ait eu un post avec cet identifiant de message qui a été envoyé par e-mail. Si vous voulez aller dans ce sens, traitez spécialement l’identifiant de message de l’OP pour qu’il soit l’identifiant de message du “sujet” au lieu de ...../1.

3 « J'aime »
29

Cela devrait être « avant l’OP ». Désolé, Cameron Simpson

30

Comme vous le dites, c’est exactement le problème qui nous frustre :

Je suis d’accord que cela devrait être modifié. L’ID de message de l’OP devrait être (en l’absence d’un message entrant par e-mail) (simplifié) topic/1 et ne pas faire référence à un autre message.

L’ID du message ne changerait pas, même s’il ne s’agissait que d’un message Discourse et jamais d’un e-mail.

Les messages ultérieurs peuvent y faire référence.

Pourquoi un e-mail doit-il exister ? Sémantiquement, avoir seulement le message correspond aux critères. Le message auquel il répond existe, juste pas dans le dossier e-mail de cette personne. Nous sommes arrivés à la conclusion que le message est ce qui est important, que ce soit le corps du message ou le corps de l’e-mail. Il s’ensuit que topic/#{topic_id}/1@site est un ID de message unique faisant référence à ce message, qu’il soit dans un message e-mail ou non.

Ce n’est pas différent de recevoir une réponse à un e-mail qui fait référence à un e-mail qui n’est pas dans votre boîte de réception. C’est toujours une réponse, donc References est légitime et correct.

Fondamentalement, je suis d’accord avec vous. Le puriste en moi veut que ce soit correct. Mais le caractère pratique de devoir faire parvenir des e-mails dans les boîtes de réception des gens a conduit à cela. Pour le pire, beaucoup de gens utilisent gmail et n’entraînent jamais ses filtres, ne l’utilisent pas correctement, et se désabonnent en signalant comme spam[^1].

[^1] : non pas que gmail nous le signale, bien que nous ayons mis en place la boucle de rétroaction.

Je suis d’accord, je pense que nous avons lu un peu trop littéralement

Un identifiant de message se rapporte à exactement une instantiation d’un message particulier

Après avoir réfléchi à cela pendant un certain temps, je pense que nous devrions revenir à ce que nous avions auparavant (supprimer la randomisation) et verrouiller un seul ID de message par publication, et ce devrait être :

  • message_id_from_incoming_email || topic/#{topic_id}/#{post_num}@site (le numéro de publication de l’OP est 1)

Et chaque fois que nous envoyons un e-mail, je pense qu’il est correct d’ajouter References à tous les parents jusqu’à l’OP et de définir In-Reply-To sur l’ID de message de publication stable approprié (ou l’OP si réponse au sujet) puisque le Message est la publication. Mais ces champs pour l’OP devraient être vides, oui.

5 « J'aime »
31

Merci pour vos réponses @supermathie et @cameron-simpson, je pense que nous sommes parvenus à un consensus. Je vais extraire les TODOs dans un seul message, et j’espère pouvoir commencer à travailler dessus très bientôt :

  1. Changer le format généré de Message-ID pour qu’il soit toujours \u003cdiscourse/post/:post_id@:hostname\u003e, c’est suffisamment unique, c’est essentiellement un retour à ce que nous faisions auparavant. La référence à l’OP utilisera maintenant le premier ID de message au lieu du simple ID de sujet.
  2. Si un message a un enregistrement IncomingEmail associé, nous utilisons toujours cet Message-ID lors de l’envoi d’e-mails, sinon nous en générons un en utilisant le format ci-dessus.
  3. Ne pas utiliser de References lors de l’envoi d’e-mails pour l’OP du sujet, il n’y a encore rien à Reference car c’est le premier e-mail du fil.
  4. Assurer que les en-têtes In-Reply-To et References corrects sont générés en fonction des enregistrements PostReply.

Cela risque de laisser les choses un peu floues en termes de fils de discussion pour les e-mails déjà envoyés, mais je ferai de mon mieux pour permettre le format dont nous nous éloignons pendant une période de transition également. Merci de votre patience !

3 « J'aime »
32

Juste pour clarifier… ce ne serait pas le hostname du serveur d’où cela provient, mais l’URL du site ? S’il s’agit du hostname, alors nous perdons toute stabilité lorsque 3 hôtes différents servent le même site.

1 « J'aime »
33

Désolé, oui, je veux dire le domaine du site, par exemple meta.discourse.org, qui provient de Email::Sender.host_for(Discourse.base_url), ce que nous utilisons déjà.

2 « J'aime »
34

Bonne idée, je n’avais pas pensé aux déplacements. Est-ce que :post_id est l’ID du message (post.id) ou son numéro (dans le sujet) ?

S’il s’agit de l’ID du message, nous pouvons simplifier et utiliser \u003cpost/:post_id@:hostname\u003e car cela ne changera jamais, nous n’aurons donc pas besoin de stocker le Message-ID sauf s’il est remplacé par défaut.

Sinon… autant utiliser l’ID du message ici ? Il n’y a aucune raison pour que cette partie doive être longue, elle doit juste être unique.

2 « J'aime »
35

C’est l’ID réel, pas le numéro du post.

C’est un bon point, <post/:post_id@:hostname> fonctionnera probablement très bien et évite l’exigence de colonne supplémentaire. Peut-être pour le rendre plus spécifique à Discourse, pourrions-nous ajouter discourse au début, par exemple <discourse/post/543563@meta.discourse.org> (en gardant à l’esprit que de nombreux sites n’auront aucune mention de Discourse dans le nom d’hôte). C’est pinailler à ce stade cependant.

Je vais essayer de penser à des façons dont cela pourrait mal tourner. Je suppose que si vous déplacez un post vers un autre sujet, puis que quelqu’un répond au post par e-mail, sa réponse se retrouvera dans le nouveau sujet au lieu du sujet d’origine. Peut-être que ce n’est pas grave ? L’autre risque est que le post soit déplacé dans une catégorie privée, mais je pense que nous avons déjà le même risque et que nous le gérons.

Je réfléchis à voix haute, ça devrait aller, je couvrirai ces points lorsque je testerai les changements de toute façon :+1:

2 « J'aime »
36

L’argument en faveur de l’inclusion de topic_id est que vous pouvez délibérément casser le fil de discussion si les gens séparent un message d’un sujet dans un autre sujet.

Je suis partagé à ce sujet. Je peux aller dans un sens ou dans l’autre. Mais telle serait l’idée.

1 « J'aime »
37

L’argument en faveur de l’utilisation uniquement de l’ID de publication est qu’il est plus statique, ce que nous voulons, car si vous déplacez une publication vers un autre sujet, l’ID de publication sera le même dans le Message-ID, mais le sujet ne sera pas le même.

Je pense que si nous finissons par déplacer la publication et envoyer des e-mails à partir du nouveau sujet, le nouveau fil de discussion sera créé correctement de toute façon dans le client de messagerie, car les chaînes d’en-tête References et In-Reply-To seront différentes. Quoi qu’il en soit, je m’assurerai de tester ce scénario et de voir s’il fait ce que nous attendons également. Rien ne sera fusionné dans le cœur tant que les différents scénarios ne fonctionneront pas comme prévu.

1 « J'aime »
38

Suite à ces discussions supplémentaires @cameron-simpson, j’ai mis à jour les TODOs comme suit, je les poste ici afin que vous receviez la mise à jour car les modifications Discourse n’arriveront pas par e-mail :

  1. Changer le format du Message-ID généré pour qu’il soit toujours \u003cdiscourse/post/:post_id@:hostname\u003e, c’est suffisamment unique, c’est en fait un retour à ce que nous faisions auparavant. La référence à l’OP utilisera maintenant l’ID du premier message au lieu de simplement l’ID nu du sujet.
  2. Si un message a un enregistrement IncomingEmail associé, nous utilisons toujours ce Message-ID lors de l’envoi d’e-mails, sinon nous en générons un en utilisant le format ci-dessus.
  3. Ajouter une nouvelle colonne outbound_message_id aux enregistrements Post qui sera remplie soit par a) le Message-ID de l’e-mail entrant s’il crée le message, soit par b) le Message-ID sortant que nous générons dans le cas des messages créés par l’interface web Discourse.
  4. Ne pas utiliser d’en-têtes References ou In-Reply-To lors de l’envoi d’e-mails pour l’OP du sujet, il n’y a rien à Reference ou à répondre car c’est le premier e-mail du fil.
  5. S’assurer que les en-têtes In-Reply-To et References corrects sont générés en fonction des enregistrements PostReply.
1 « J'aime »
39

Est-ce que cela couvre également les citations (par exemple, un message qui cite 10 autres messages, donc il y fait référence ?)

1 « J'aime »
40

Par Sam Saffron via Discourse Meta le 29Juillet2022 02:31 :

Est-ce que cela couvre aussi les citations (par exemple, un message citant 10 autres messages, donc il y fait référence ?)

In-Reply-To ne peut citer qu’un seul antécédent, donc choisissez-en un. References peut en référencer plusieurs, mais la RFC le déconseille explicitement car toutes les applications clientes ne s’attendent pas à autre chose qu’une chaîne linéaire de ce message jusqu’à l’OP.

Je serais d’accord avec l’un ou l’autre pour References, mais je pencherais pour le plus conservateur. Le calcul simple est :

  • In-Reply-To : utilisez l’ID du message du premier message cité (ou tout autre message cité unique que vous choisissez selon une politique)
  • References : les References du même antécédent unique choisi ci-dessus plus l’ID de ce même message

Ce serait stable, prévisible et correct.

Cordialement,
Cameron Simpson cs@cskk.id.au

2 « J'aime »
41

References est déconseillé d’être utilisé de cette façon :

Remarque : Certaines implémentations analysent le champ « References: » pour afficher le « fil de la discussion ». Ces implémentations supposent que chaque nouveau message est une réponse à un seul parent et qu’elles peuvent donc remonter le champ « References: » pour trouver le parent de chaque message qui y est répertorié. Par conséquent, il est déconseillé d’essayer de former un champ « References: » pour une réponse qui a plusieurs parents ; la manière de le faire n’est pas définie dans ce document.

2 « J'aime »
42

Par Martin Brennan via Discourse Meta le 29Juillet2022 01:57 :

Sur la base de ces discussions supplémentaires @cameron-simpson, j’ai mis à jour les TODOs
pour ceci, en les publiant ici afin que vous receviez la mise à jour car les modifications Discourse
n’arriveront pas par e-mail :

  1. Changer le format du Message-ID généré pour qu’il soit toujours \u003cdiscourse/post/:post_id@:hostname\u003e, c’est assez unique, c’est en fait un retour à ce que nous faisions auparavant. La référence à l’OP utilisera maintenant l’ID du premier message au lieu de simplement l’ID du sujet nu.
  2. Si un message a un enregistrement IncomingEmail associé, nous utilisons toujours ce Message-ID lors de l’envoi d’e-mails, sinon nous en générons un en utilisant le format ci-dessus.
  3. Ne pas utiliser de References lors de l’envoi d’e-mails pour l’OP du sujet, il n’y a rien à Referencer car c’est le premier e-mail de la conversation.

J’omettrais également le In-Reply-To dans les e-mails de l’OP.

  1. Assurer que les en-têtes In-Reply-To et References corrects sont
    générés en fonction des enregistrements PostReply.

Oui.

Personnellement, j’irais plus loin en ayant une colonne pour le message-id côté e-mail. Ainsi, une fois que vous avez attribué un message-id à un message (provenant de l’e-mail source s’il provient d’un e-mail, ou généré s’il provient de l’interface web), il reste stable, quelles que soient les autres modifications qui pourraient survenir dans le code maintenant ou plus tard. C’est-à-dire que même s’il n’y a pas d’IncomingEmail, la génération du message-id ne se produit qu’une seule fois, plutôt que d’être recalculée (ce qui pourrait donc changer).

C’est-à-dire, le rendre stable une fois créé en le stockant.

Vous avez une relation IncomingEmail d’après ce que je vois. Peut-être avez-vous (ou pourriez-vous utiliser) une relation OutgoingEmail pour l’état supplémentaire des messages sortants, créée la première fois qu’un message est transféré par e-mail.

Je sais que le flux est essentiellement ce qui se passe lorsqu’un message est créé, mais je peux imaginer certaines fonctionnalités utilisateur ultérieures telles que :

  • veuillez me transférer les e-mails pour l’ensemble de ce sujet, maintenant que je suis intéressé
  • si une modification est apportée à un message, envisagez d’envoyer le message mis à jour avec le même message-id

La raison pour laquelle le deuxième exemple me vient à l’esprit est que nous avons plus de choses à signaler :slight_smile: L’une d’elles est que Discourse semble faire des efforts pour supprimer la partie citée des réponses postées en haut afin de garder le message concis, ou quelque chose comme ça. J’ai écrit un long message dans le coin de Python il y a quelques semaines qui a été sévèrement tronqué. Je suis allé le modifier sur le forum avec le texte original de ma copie personnelle. Mais un destinataire a dit qu’il avait la version complète, et je me demandais si Discourse envoyait des mises à jour d’édition sous forme de messages de remplacement avec le même id. Ce qui serait assez intéressant en fonction de la gestion par le client utilisateur final.

1 « J'aime »
43

Par Martin Brennan via Discourse Meta le 29Juillet2022 00:36 :

  1. Ajouter un nouvel outbound_message_id à la table Post, afin que nous puissions être sûrs que le fil de discussion survit même si un message change de sujet ou quoi que ce soit de ce genre, stocker le Message-ID ici pour les deux cas ci-dessus.

Oui, je pense que c’est important, quelle que soit la manière dont c’est implémenté (relation ou colonne de quoi que ce soit). Je pense que je l’ai dit dans vos TODOs révisés.

  1. Ne pas utiliser de References lors de l’envoi d’e-mails pour l’OP du sujet, il n’y a rien à Référencer pour l’instant car c’est le premier e-mail du fil de discussion.
  2. 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 de la table Post.

Cela a le potentiel de laisser les choses dans un état un peu trouble en termes de fil de discussion pour les e-mails déjà envoyés, mais je ferai de mon mieux pour permettre le format dont nous nous éloignons pendant une période de transition également. Merci de votre patience !

Il n’y a rien que nous puissions faire pour les e-mails existants. Assurez-vous simplement que les choses sont bien en fil de discussion à l’avenir !

Merci !
Cameron Simpson cs@cskk.id.au

1 « J'aime »
44

Nous avons EmailLog mais ces enregistrements sont nettoyés tous les 90 jours, et je ne pense pas que ce serait une bonne solution. Je vais juste faire ceci :

1 « J'aime »
45

Il s’agissait d’éviter de le stocker du tout… mais maintenant que j’y pense, l’ID du post ne changera jamais, mais le nom d’hôte pourrait changer. Nous devrions donc le stocker immédiatement après l’enregistrement dans tous les cas.

Cela ne pourrait pas nuire d’avoir messageid comme propriété de chaque Post, immuable pour toujours…

Ne serait-ce pas une version différente du message ? D’après la spécification :

Le champ “Message-ID :” fournit un identifiant de message unique qui fait référence à une version particulière d’un message particulier. … Un identifiant de message concerne exactement une version d’un message particulier ; les révisions ultérieures du message reçoivent chacune de nouveaux identifiants de message.

Donc, probablement, notre message-id généré devrait être : \u003cdiscourse/post/:post_id/rev/:revision_num\u003e (en omettant éventuellement /rev/:revision_num pour la première révision). Cela permettrait aux destinataires d’e-mails de recevoir les mises à jour de modification en premier lieu, étant donné que

1 « J'aime »
46

Oui, je vais faire ça. Quant à ces autres discussions sur les modifications et les révisions, je pense que c’est une tout autre paire de manches dans laquelle nous ne devrions pas nous lancer maintenant… réglons d’abord nos péchés de discussion :slight_smile:

1 « J'aime »