Auf discuss python org diskutieren wir die E-Mail-Seite von Discourse. Die größte Beschwerde ist das Fehlen von Threading. Ich habe die Header etwas untersucht und es scheint, dass:
Der Message-ID-Header zumindest eindeutig ist
Die Header Reply-To und Referencesnicht auf die Message-IDs anderer Nachrichten verweisen, geschweige denn auf die Message-ID der Nachricht, auf die sie eine Antwort sind
Sie stattdessen auf eine fiktive Message-ID verweisen, die auf der Topic-Nummer basiert
Das bedeutet, dass E-Mail-Benutzer (a) völlig flache, nicht-verschachtelte Diskussionen sehen und (b) die Stamm-Nachricht anscheinend fehlt, da die Header In-Reply-To und References auf eine Message-ID verweisen, die in keiner Nachricht tatsächlich vorkommt.
Das ist schlecht und verstößt gegen RFC 5322. Und es macht die E-Mail-Erfahrung weitaus schlechter, als sie leicht sein könnte.
Als Beispiel gibt es dort einen Thread, dessen erste Nachricht diese Header hat:
Wieder eine ok Message-ID, aber völlig unsinnige In-Reply-To- und References-Header.
Das sollte einfach zu beheben sein. Die erste Nachricht sollte weder In-Reply-To- noch References-Header haben. Die zweite Nachricht sollte die Message-ID der ersten Nachricht in den Headern In-Reply-To und References haben.
Bitte beachten Sie RFC5322 Abschnitt 3.6.4 für Details:
So wie die Dinge sind, sehen E-Mail-Benutzer flache, unstrukturierte Diskussionen. Mit diesen Korrekturen können sie eine sinnvolle, leicht verständliche verschachtelte Anzeige erhalten.
Ich schaue mir gerade den Unterschied zwischen HEAD und diesem Fix an.
Mir scheint, dass References immer noch gesetzt wird, auch wenn es keinen Vorgänger gibt – topic_canonical_reference_id wird als Fallback verwendet. Ich halte das immer noch für falsch, da es keine E-Mail-Nachricht mit dieser ID gibt.
In-Reply-To ist etwas korrekter, da es nur gesetzt wird, wenn post.post_number!=1, aber es greift immer noch auf topic_canonical_reference_id zurück:
Das scheint zwei Probleme zu haben, wie ich es sehe:
Der Fallback sollte die Message-ID von Beitrag #1 sein, wenn keine referenced_post_message_ids vorhanden sind, und nichttopic_canonical_reference_id.
Etwas im receipt-of-reply-emails-Code muss den In-Reply-To-Header der Antwortnachrichten fallen lassen, da diese das referenced_post_message_ids-Array korrekt hätten füllen sollen (“Liste”? Ich bin neu in Ruby).
Cameron, danke, dass du dieses Thema zur Diskussion gestellt und viele Details in deinen Beiträgen geliefert hast. Ich bin für diesen Büchsen der Pandora verantwortlich, von diesen beiden Commits:
Wir sind uns seit einiger Zeit einiger Probleme mit dem Threading in E-Mail-Clients wie Thunderbird bewusst, aber es gab nicht viele Nutzer von E-Mail-Threading aus Discourse, daher wurde es aufgeschoben. Aber jetzt, da dies ans Licht kommt, müssen wir einige Zeit darauf verwenden, das Problem erneut zu untersuchen und an einer Lösung zu arbeiten.
Interessanterweise haben wir diesen References-Header bei der ersten gesendeten E-Mail und bei jeder nachfolgenden E-Mail hinzugefügt, da er das korrekte Threading in Gmail ermöglicht. Aber ich stimme zu, dass es nicht ideal ist und wahrscheinlich die Threading-Probleme verursacht, zusammen mit der Nichtverwendung der ursprünglichen Message-ID in den In-Reply-To- und References-Headern der nachfolgenden E-Mails.
Bitte habt Geduld mit mir, während ich alte Diskussionen und den Code durchsehe und dies ausarbeite. In der Zwischenzeit, sind dir andere E-Mail-Clients bekannt, die verwendet werden und Probleme haben? Ich weiß zum Beispiel, dass dies ein Problem in Thunderbird ist, aber was ist mit anderen? Danke.
Ich habe eine lange Antwort geschrieben, aber Folgendes erhalten:
Es tut uns leid, aber Ihre E-Mail-Nachricht an
["incoming+8349bd9eb1f2b582df4f32dbe85c3363@meta.discoursemail.com"]
(Betreff: Re: [Discourse Meta] [bug] Discourse-E-Mail-Nachrichten werden
falsch geordnet) hat nicht funktioniert.
Grund:
Entschuldigung, neue Benutzer können nur 2 Links in einen Beitrag einfügen.
Wenn Sie das Problem beheben können, versuchen Sie es bitte erneut.
Ich werde sie jetzt ins Forum stellen, wo ich sie noch bearbeiten kann…
Cameron, danke, dass du dieses Thema zur Diskussion gestellt und viele Details in deine Beiträge aufgenommen hast. Ich bin für diesen Dosenöffner verantwortlich, aus diesen beiden Commits:
3b13f1146b2a406238c50d6b45bc9aa721094f46
Das sieht gut aus. Wird diese ID mit dem DB-Eintrag gespeichert, damit eingehende Antworten mit der vorherigen Forennachricht verknüpft werden können?
Möchtest du auch, dass ich überprüfe, ob der Suffix syntaktisch für RFC5322 zulässig ist, in Bezug auf erlaubte Zeichen?
82cb67e67b83c444f068fd6b3006d8396803454f
Dieser zweite Commit scheint ein weiteres Problem zu lösen, das wir gesehen haben: Wenn ein Beitrag aus einer E-Mail stammt, ist die ausgehende Message-ID, die an E-Mail-Benutzer gesendet wird, nicht die Message-ID der Quellnachricht des Autors. Dies führt dazu, dass zwei verschiedene Nachrichten aus Sicht eines Mail-Clients entstehen, und wahrscheinlich werden Antworten an das Original im Gegensatz zur Forum-gesendeten Kopie unterbrochen. Zum Beispiel:
An: das Forum
CC: einer der Teilnehmer
Der Teilnehmer erhält (nun ja, möglicherweise) eine Kopie vom Forum und eine direkte Kopie vom Autor, und dies werden unterschiedliche Nachrichten auf ihrer Seite sein, da sie unterschiedliche Message-IDs haben werden.
Ich wollte nach der Klärung des Problems mit den Headern “in-reply-to” und “references”, das weitaus wichtiger ist, einen zweiten Fehlerbericht zu diesem Thema erstellen.
Wir sind uns seit einiger Zeit einiger Probleme mit dem Threading in E-Mail-Clients wie Thunderbird bewusst, aber es hat keine große Anzahl von Nutzern von E-Mail-Threading aus Discourse dargestellt, daher wurde es aufgeschoben, aber jetzt, da dies ans Licht kommt, müssen wir einige Zeit damit verbringen, das Problem erneut zu untersuchen und an einer Lösung zu arbeiten.
Ich und mehrere andere verwenden mutt. Ich bin gerne bereit, alles zu tun, was zur Unterstützung beim Debugging und zur Überprüfung von Code erforderlich ist. Ich war auch in früheren Leben lange Zeit Mail-Sysadmin.
[quote=“Cameron Simpson, post:1, topic:233499,
username:cameron-simpson”]
Es ist die erste Nachricht. Sie sollte keinen References-Header haben, da es nirgendwo eine Nachricht mit dieser ID gibt.
[/quote]
Interessanterweise haben wir diesen References-Header zu der Zeit zur ersten gesendeten E-Mail und zu jeder nachfolgenden hinzugefügt, da dies das Threading in Gmail korrekt funktioniert.
Ich denke, ein korrekter References-Header (abwesend in der ersten Nachricht, wie in-reply-to in Antworten) sollte auch funktionieren. Aber GMail hat manchmal eine eher lockere Beziehung zu Mail-Standards. Ich habe eine Gmail-Vereinbarung; ich kann dort auch einige Debugging-Arbeiten durchführen. Und im Prinzip können wir diese sehr Diskussion als Testfeld nutzen, vielleicht.
aber ich stimme zu, dass es nicht ideal ist und wahrscheinlich die Threading-Probleme verursacht
zusammen mit der Nichtverwendung der ursprünglichen Message-ID in den nachfolgenden E-Mail- In-Reply-To- und References-Headern.
Bitte haben Sie Geduld mit mir, während ich alte Diskussionen und den Code durchsehe und mich damit beschäftige.
Kein Problem.
In der Zwischenzeit, sind Sie sich anderer E-Mail-Clients bewusst, die verwendet werden und Probleme haben? Zum Beispiel weiß ich, dass dies ein Problem in Thunderbird ist, aber was ist mit anderen? Danke.
Definitiv mutt. Zumindest mit mutt ist es sehr einfach, die Header zu sehen und auch die Antwort-Baumkette zu sehen, die in anderen Clients oft verdeckt ist.
Mail-Threading wird vollständig durch die Header Message-ID und In-Reply-To definiert. Der References-Header begann mit USENET für Follow-ups und unterstützte (dort) mehrere Message-IDs; der In-Reply-To unterstützt nur einen. Es sieht so aus, als ob References jetzt auch in RFC5322 vorhanden ist, und ich werde seine Semantik prüfen.
Okay, das ist ziemlich viel, bitte haben Sie etwas Geduld. Zuerst einmal vielen Dank für eine weitere detaillierte Antwort und das Angebot zum Debugging/Review, es ist wirklich hilfreich Ich habe mir das heute Morgen tatsächlich angesehen und überraschenderweise funktioniert das Threading in einer einheitlichen Ansicht in Thunderbird in den meisten Fällen, und ich denke, der References-Header, der konsistent auf den OP verweist, hilft dabei (zum Beispiel ist der Thema-Reference in dieser Kette, der immer vorhanden ist, \u003ctopic/53@discoursehosted.martin-brennan.com\u003e).
Der Fall, in dem das Threading nicht wie beabsichtigt funktioniert, ist:
Ein Beitrag wird innerhalb von Discourse erstellt und eine E-Mail wird an diejenigen gesendet, die das Thema beobachten dann
Jemand anderes antwortet auf diesen Beitrag und eine E-Mail wird an diejenigen gesendet, die das Thema beobachten
Im Fall der zweiten E-Mail erhält sie einen falschen In-Reply-To- und References-Header, da sie einen in dieser Zeile generiert: discourse/lib/email/sender.rb at 98bacbd2c6b9fe57167cd32af5eb4839b4a5d1f6 · discourse/discourse · GitHub, anstatt einen vorhandenen zu verwenden. Sie sollte die Message-ID für die zuerst gesendete E-Mail verwenden. Im Screenshot ist dies, wo die Nachrichten, die diesem Muster folgen, platziert werden sollten:
Die Antwort ist – es kommt darauf an. Wenn ein Beitrag aus einer eingehenden E-Mail in Discourse erstellt wird, wie z. B. dieser von Ihnen, verwenden wir die ursprüngliche eingehende Message-ID dieses Beitrags, wenn jemand darauf antwortet, für die Header In-Reply-To und References, wie hier beschrieben:
Andernfalls verwenden wir einfach die Referenz des Thema-OP und generieren eine neue Referenz, was offensichtlich die Ursache für alle Probleme ist. In allen Fällen generieren wir jedes Mal eine neue Message-ID, wenn eine ausgehende E-Mail gesendet wird, was korrekt und auf Augenhöhe mit anderen E-Mail-Clients zu sein scheint.
Ich glaube, ich verstehe, was Sie meinen. Geht es so:
Cameron sendet eine E-Mail an Discourse von Mutt, die Message-ID: 74398756983476983@mail.com erhält
Discourse erstellt einen Beitrag und speichert die Message-ID gegen den Beitrag mit einem IncomingEmail-Eintrag
Johndoe beobachtet das Thema, also erhält er eine E-Mail von Discourse mit einer Message-ID: topic/222/44@discourse.com und ohne Bezug auf die ursprüngliche Message-ID: 74398756983476983@mail.com
Klingt das richtig, dass wir diese Message-ID einfach an diejenigen weitergeben sollten, die das Thema beobachten, anstatt unsere eigene zu generieren, da sie bereits eindeutig ist? Was passiert dann im E-Mail-Client von Johndoe, wenn
Cameron ihn auch auf diese ursprüngliche ausgehende Nachricht CC’d hat? Dies scheint ein separates Problem zu sein, daher wäre es gut, ein weiteres Bug-Thema dafür zu eröffnen.
Ich werde lokal einen Mutt-Client einrichten, um zu sehen, was Sie auch sehen. Ich habe diese Funktionalität noch nie in einem textbasierten Client getestet (nur Gmail und Thunderbird), daher bin ich gespannt, wie es aussieht.
Meine Überlegung, um diese Probleme heute Morgen anzugehen, war, die zufällig generierten Suffixe zu verwerfen, die wir beim Senden von Message-ID-Headern in E-Mails generieren, und stattdessen ein Schema zu verwenden, bei dem wir die user_id des sendenden und empfangenden Benutzers verwenden. Der Vorteil davon ist, dass die Message-ID nirgendwo gespeichert werden muss (außer wenn eine eingehende E-Mail einen Beitrag erstellt) und somit die Header References und In-Reply-To immer konsistent sind. Lassen Sie mich ein Beispiel geben. Nehmen wir an, wir haben diese Benutzer:
Martin – user_id 25
Cameron – user_id 44
Sam – user_id 78
Bob – user_id 999
Und dann haben wir dieses Thema, topic_id 233499, mit Beiträgen ab post_id 100 als OP. Das Format wäre topic/#{topic_id}/#{post_id}.s#{sender_user_id}r#{receiver_user_id}. Die Reihenfolge der Operationen würde wie folgt aussehen:
Bob erstellt Beitrag 103 im Thema, nicht als Antwort auf jemanden (beachten Sie, dass References hier die Message-ID enthält, die an beide Benutzer für die OP-E-Mail gesendet wurde)
Bob – Antwort im Thema, nicht auf einen bestimmten Beitrag
GESENDET → an: Discourse, RE: Bobs Beitrag
Sams Posteingang
Martin – Thema OP
Cameron – zweiter Beitrag
GESENDET → an: Discourse, RE: zweiter Beitrag
Bob – Antwort im Thema, nicht auf einen bestimmten Beitrag
Ich denke, das ist richtig, können Sie sich bitte ansehen, was ich in diesen Headern geschrieben habe, und bestätigen, dass dies das ist, was Sie von diesem Szenario erwarten würden? Das Einzige, worüber ich mir ein wenig unsicher bin, ist, ob ich alle Referenzen abgedeckt habe, und natürlich würde ich dies an einem Live-Datensatz von E-Mails in einem Entwicklungszweig testen, bevor ich es ausrolle. Ich habe auch noch nichts in Mutt getestet.
Nebenbei bemerkt, habe ich mir auch angesehen, was GitHub mit seinen Benachrichtigungs-E-Mails macht, und festgestellt, dass sie etwas Ähnliches tun, wo sie eine allgegenwärtige Reference (discourse/discourse/pull/252@github.com) haben, die in allen E-Mails verwendet wird, die sich auf dieses “Thema” beziehen, das in diesem Fall eine GitHub-Pull-Anfrage ist:
By Martin Brennan via Discourse Meta at 22Jul2022 06:34:
Okay this is kind of huge, please bear with me. First, thanks for
another detailed reply and the offer of debugging / review, it is
really helpful I’ve actually been looking into this this morning
and, surprisingly, the threading in a unified view works in Thunderbird
for most cases, and I think the References header consistently
pointing to the OP helps with that (for example the topic Reference
in this chain which is always present is <topic/53@discoursehosted.martin-brennan.com>.
I’ve just reread RFC5322 section 3.6.4 closely. It has moved on from
earlier versions (822 and 2822), and has merged the email In-Reply-To
headers, USENET References headers and modern
reply-citing-more-that-one previous messages.
The short summary:
The Message-ID is a single persisent identifier for a message
The In-Reply-To contains all the message-ids of which this message
is a direct reply, so if I reply to a pair of messages it will have
those 2 message-ids
The References is a reply chain of antecedant message-ids from the
OP to the preceeding message. So indeed it should always start with
the OP message-id.
So for a discussions like this, pretending that labels are message-ids:
It is also leagel to include “reply1 reply2” in the references (the
other chain to reply5) but the RFC explicitly recommends against that
becaause some clients expect the references to be a single linear chain
of replies, not some flattened digraph.
So my recommendation for constructing the references is to use the
references of the “primary” antecedant message with the primary
antecedant message’s message-id appended. That way you always get a
linear chain in the correct order.
Interestingly there seems to be some threading there.
But notice: the top post has a little “is a reply” arrow. Even though it
is post 1. I expect that is because of the “topic” references entry,
which make TB think there was a earlier message (which of course there
was not).
In mutt-land we see almost no threading at all:
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
which is because every message’s In-Reply-To points directly at the
fictitious “topic” message-id. Mutt probably ignores the References
because it is a mail reader, and References originates in USENET news.
Maybe Thunderbird is using the references or augumenting the in-reply-to
with references information.
You only need to consult one of In=-Reply-To or References to do
threading; the former comes from email and the latter from USENET.
You’re supporting both (which is great!) so we need to make them
consistent.
(Aside: there’s also discussion about USENET mirroring, because several
python people consume the lists via a USENET interface. Again, a
separate topic.)
[…]
[quote=“Cameron Simpson, post:8, topic:233499,
username:cameron-simpson”]
This looks fine. Does it save this id with the db record so that inbound
replies can be tied to the antecedant forum message?
[/quote]
The answer is – it depends. If a post is created in Discourse from an inbound email, such as this one of yours, we use that post’s original inbound Message-ID when someone replies to it for the In-Reply-To and References headers as per:
Otherwise we are just using the topic OP reference and just generating a new reference, which obviously is what is causing all the issues. In all cases we generate a new Message-ID every time an outbound email is sent, which seems correct and on par with other mail clients.
Alas, not quite. If you’re the origin of the message (i.e. authored in
Discourse), generating the message-id is fine. If there’s no message-id
(illegal) generating one is standard practice (usually by MTAs). But if
you’re passing a message on (authored in email), the existing message-id
should be preserved.
To my mind you need to be doing 3 things:
having a stable message-id and not replacing the message-id from an
inbound message
generating correct In-Reply-To, which is easily computed from the
immediate antecedant message(s) i.e. antecedant(s)-Message-ID
generating correct References, which is easily computed as
antecedant-References + antecedant-Message-ID
For point 1, looking at the code you cite, you probably want the email
message id to be (Pythonish syntax, sorry):
def message_id(post):
return post.incoming_email.message_id or discourse_message_id(post)
i.e. to be the post’s email message-id if it originated from email,
otherwise the Discourse message-id using something like the algorithm
you outline later in this message: anything (a) stable and (b)
syntacticly valid.
Then computing the In-Reply-To and References fields is simple
mechanical stuff as in points 2 and 3.
I think I see what you mean, does it go like this:
cameron sends email to Discourse from mutt which gets Message-ID: 74398756983476983@mail.com
Discourse creates a post and stores the Message-ID with against the post with an IncomingEmail record
Correct.
johndoe is watching the topic, so they get sent an email from Discourse with a Message-ID: topic/222/44@discourse.com and no reference to the original Message-ID: 74398756983476983@mail.com
No. You really want to pass through IncomingEmail.message_id as the Message-ID in the email to johndoe. It’s the same message.
Does that sound correct, that we should just “pass on” that Message-ID to those watching the topic instead of generating our own since it’s already unique? What then happens in johndoe’s mail client if
cameron also CC’d him on that original outbound message? This does sound like a separate issue so it would be good to open another bug topic for it.
By passing it on, the original message (cameron->cc:johndoe) and the
Discourse forwarded message (cameron->Discourse->johndoe) have the same
message-id and the same message contents. The receiving mail system
stores both. The mail reader sees both, and either presents both or
keeps just one (this is a policy decision of the mail reader - keeping
just one is common). Because they’re the same message, in general it
does not matter which is kept.
If we ignored discourse and considered a message which was
a copy of the message via the list and also via direct email. They’re
the same message, with the same message-id.
I will set up a mutt client locally to see what you are also seeing, I have never tested this functionality in a text-based client (only Gmail and Thunderbird) so I am keen to see how it looks anyway.
Happy to help with settings. For threaded view you need to set the
sorting to threadeed. Mutt is very configurable.
My line of thinking to address these issues this morning was to dispose
with the randomly generated suffixes generated when we send Message-ID headers in emails and instead change to a scheme where we
use the user_id of both the sending and receiving user. The benefit
of this is that there is no need to store the Message-ID anywhere
(apart from when an inbound email creates a post) and so References
and In-Reply-To headers will always be consistent.
Yes, that is much better. Noting that the inbound email message-id
should override the Discourse derived message-id for the outbound email.
(Most mail systems use random strings because there’s no surrounding
context such as the discourse topic message structure - messages are
considered alone; but the only real requirement is persistent
uniqueness.)
Let me give an example. Say we have these users:
martin - user_id 25
cameron - user_id 44
sam - user_id 78
bob - user_id 999
And then we have this topic, topic_id 233499, with posts starting from post_id 100 as the OP. The format would become topic/#{topic_id}/#{post_id}.s#{sender_user_id}r#{receiver_user_id}.
There should not be a References header in the OP. It isn’t
needed for threading and effectively pretends there’s some “post 0”
which doesn’t exist. It meeans every OP (a) looks like a reply, which it
is not and (b) looks like the thing to which it is a reply is missing
from the reader’s mailbox.
This makes different message-ids for each outbound copy of the OP.
That’s bad. They need to be the same. Supposing sam CCs cameron
directly in a reply. The In-Reply-To will cite a mesage-id cameron
has never received.
You can just drop the sender_user_id and receiver_user_id from the
message-id field and get a single unique id which every receiver sees.
The uniqueness constraint is the post itself, not the individual
email-level “message” object.
Re the References, the OP should not have one. TB and everything else
will be fine. If they’re threading using References instead of In-Reply-To, the References in the reply messages are enough.
Here’s the start of a mailing list discussion thread in 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
Ignore that I sort my email newest-on-top. See that there’s no arrow on
the initial post (at the bottom). That messgae has no References and
no In-Reply-To. All the others have In-Reply-To (and possibly References, but this is an email mailing list so not necessarily; as I
mentioned before they’re complimentary.)
If I repeat my Discourse example from earlier:
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
See they all have a leading arrow? That is because the mail client
believes they are all replies to a common (and missing) root message,
which is because of the “topic” message-id in the References header.
Whereas post 1 is actually the bottom message displayed above.
Summary:
your plan is good, provided you drop the sender and receiver from the
message-id - they’re unnecessary and in fact the receiver will cause
trouble (the sender is just redundant).
drop the “topic” pseudo-message-id from the References - it misleads
email clients (including TB, even if it isn’t visually evident)
cameron replies via email
discourse is sent an email with these headers from mutt:
Yes, again with the caveat that there should not be a “topic” reference.
As expected, there is a reference to the OP message-id. Though it should
be the same message-id that sam sees for the OP.
discourse (as cameron, from the above email) creates post 101
sam is sent an email from discourse with these headers:
And here it goes wrong. The Message-ID should be 43585349859734@test.com from the .incoming_post.message_id field.
(Well, in my mind this is post.message_id(), which returns post.incoming_post.message_id for an email generated post and your
Discourse generated one otherwise).
Consider: I compose and send my reply with message-id 43585349859734@test.com. For continuity reasons, I keep a copy of that
in my local folder, where it shows as a reply to the OP. Ideally
Discourse also sends me a copy of my own post (this is a policy setting
on many mailing lists), so I get Discourse’s version also. That should
have the same message-id, because it is the same message, just via a
different route.
Discourse’s message is not “in reply to” my message. It is my
message, just forwarded.
This effect cascades through your following examples. The actual process
should be simpler than you’ve made it.
Think of it this way. If I reply to a post from email, it effectively is
like me emailing sam (and the others) via Discourse. Discourse
forwards my message to the email-receiving subscribers, and
“incidentally” keeps a copy on the forum
As a side note, I also looked into what GitHub do with their
notification emails, and noticed they do a similar thing where they
have an ever-present Reference
(discourse/discourse/pull/252@github.com) that is used in all the
emails related to that “topic” which in this case is a GitHub pull
request:
Hoo, github. What a disaster their issue emails are
However, in their scenario, the PR is the OP. So a reference directly
to the pull is sane. You could use the “topic” message-id for post 1,
provided you didn’t also use the “topic/1” id as well. But there seems
little point - it is extra effort to special case post 1 - I’d just use
“topic/1” myself.
To add some complication. As I understand it, an admin can move a post
or topic. Doesn’t that break the “generate the message-id” scheme,
particularly if they move just a post? I’m somewhat of the opinion that
every post should have a _message_id field, filled in from the
incoming message (from email) or generated (posting via Discourse). Then
it is persistent and stable and robust against any shuffling of posts or
changes of algorithm.
Finally, there’s a small security consideration: you should ignore the
inbound email message-id (and potentially bounce the message) if it
claims the message-id of an existing post. Since as an author, I can put
anything I like in that header I’d go with just dropping the
message-id - accept the post, but don’t let it lie about being some
other post - give your copy the Discourse-generated id and then proceed
as normal.
Vielen Dank nochmals für diese wunderbar ausführliche Antwort. Es wird wahrscheinlich eine Weile dauern, bis ich dies verarbeitet und in umsetzbare Punkte umgewandelt habe. Bitte haben Sie also etwas Geduld mit uns (außerdem habe ich einige andere interne Projekte mit hoher Priorität, an denen ich gerade arbeite). Ich denke, mit diesen Informationen werden wir in der Lage sein, unsere Threading-Systeme viel robuster und spezifikationsgerechter zu gestalten. Möglicherweise habe ich weitere Fragen, wenn ich Ihren Beitrag durchgehe. Danke, Cameron.
Von Martin Brennan via Discourse Meta am 25. Juli 2022 00:28:
Wow, danke nochmals für diese wunderbar ausführliche Antwort. Es wird
wahrscheinlich eine Weile dauern, bis ich das verarbeitet und in
umsetzbare Punkte umgewandelt habe, also haben Sie bitte etwas Geduld mit uns (außerdem habe ich derzeit einige andere interne Projekte mit hoher Priorität, an denen ich arbeite). Ich
denke, mit diesen Informationen werden wir in der Lage sein, unsere Threading-Systeme viel robuster und spezifikationsgerechter zu machen. Ich habe möglicherweise weitere Fragen, wenn ich Ihren Beitrag durchgehe, danke Cameron.
Ah, das ist eine interessante Beobachtung, ich hatte den kleinen Pfeil nicht bemerkt.
Das ist auch super interessant. Ich glaube (ohne den Quellcode zu prüfen), dass Thunderbird das tut, und wahrscheinlich auch die Gmail-Oberfläche, da sie dasselbe tut.
Das scheinen wir zu tun, aber ich schätze, nicht konsequent? Grundsätzlich müssen wir sicherstellen, dass:
TODO #1 - Wenn ein Beitrag einen zugehörigen IncomingEmail-Datensatz hat, verwenden wir immer diese Message-ID, wenn wir E-Mails senden.
TODO #2 - Verwenden Sie keine References, wenn Sie E-Mails im Zusammenhang mit dem OP des Themas versenden.@cameron-simpson eine Frage – wenn der OP über eine eingehende E-Mail erstellt wurde, würden wir dann diese Message-ID in References für den OP verwenden oder sie trotzdem ausschließen?
Das ist interessant, ich dachte, jeder Empfänger der E-Mail müsse eine eindeutige Message-ID haben? Tatsächlich glaube ich, dass wir deshalb dazu übergegangen sind, die Message-ID jedes Empfängers eindeutig zu machen, um Spam-Verhalten zu vermeiden, wenn ich an unseren internen Thread zurückdenke. Vielleicht könnte @supermathie, der in unserem Infrastrukturteam ist und Anfang des Jahres viel mit E-Mails getestet hat, hier auch etwas dazu sagen?
Sie sagen also, dass der Beitrag eher die Sache ist, die eine einzige Message-ID für alle Empfänger bestimmt. Vielleicht generieren wir also einfach eine für jeden Beitrag, der eine E-Mail generiert? Dann könnten wir auch die IncomingEmail.message_id hierher verschieben. Vorläufige Änderung, die wir vornehmen müssten:
TODO #3 - Fügen Sie der Post-Tabelle ein outbound_message_id hinzu. Generieren Sie es einmal, wenn eine E-Mail zum ersten Mal in Bezug auf den Beitrag gesendet wird. Verwenden Sie es für nachfolgende References- und In-Reply-To-Header. Setzen Sie seinen Wert, wenn ein Beitrag aus einer IncomingEmail erstellt wird. Das Format sollte topic/:topic_id/:post_id/:random_alphanumeric_string@host sein, z. B. topic/233499/33545/gvy8475y7c45y87554c@meta.discourse.org
Nach dieser Änderung würde mein erstes Beispiel so aussehen:
Unter Berücksichtigung, dass der OP keine Sonderbehandlung mehr erfährt, wird er nicht mehr im Format topic/:topic_id@hostname sein.
TODO #4 - Stellen Sie sicher, dass korrekte In-Reply-To- und References-Header basierend auf PostReply-Datensätzen und der neuen Spalte outbound_message_id in der Post-Tabelle generiert werden.
Ich glaube, wir haben hier einige Überlegungen, ich werde das noch einmal überprüfen.
Das scheint definitiv so zu sein
Können Sie bestätigen, dass die TODOs hier vernünftig klingen, Cameron? Es scheint jetzt wirklich nicht mehr viel zu sein, wenn ich es mir ansehe. Ich frage mich auch, wenn ich diese Arbeit angehe, ob Sie bereit wären, sich einer Test-Discourse-Instanz anzuschließen, auf der die WIP-Änderungen bereitgestellt werden, damit wir E-Mails hin und her senden und testen können, ob die Dinge korrekt funktionieren? Ich werde natürlich vorher meine eigenen Tests durchführen, bevor ich Sie einbeziehe.
Wenn nicht, ist das auch in Ordnung – ich habe Thunderbird und werde mutt einrichten und kann alles dort testen
@cameron-simpson Eine Sache, die ich hier klären wollte, ist der Geltungsbereich von „message_id“.
Der Auslöser für diesen ganzen Tanz war der starke Verdacht von @supermathie, dass unsere nicht eindeutigen message_ids Probleme verursachten.
Discourse generiert für jede gesendete E-Mail eindeutige E-Mails pro Benutzer. Wenn also beispielsweise 2 Benutzer dieses Thema verfolgen:
Benutzer 1 erhält Nutzlast 1 mit einem eindeutigen Abmeldelink, der auf Benutzer 1 gerichtet ist.
Benutzer 2 erhält Nutzlast 2 mit einem eindeutigen Abmeldelink, der auf Benutzer 2 gerichtet ist.
Wenn in beiden Fällen unsere Nachrichten-ID beispielsweise discourse_topic_100/23 (topic_id/post_number) wäre, würden wir den MTAs da draußen mitteilen, dass discourse_topic_100/23 2 eindeutige Nutzlasten sein können. Die Hypothese ist, dass sie dies als Spam-Signal behandeln.
Hey Discourse … du hast gerade zwei E-Mails namens discourse_topic_100/23 gesendet, was ist los?
Da Discourse die gesamte E-Mail-Übertragung kontrolliert und E-Mails nicht wie bei herkömmlichen Mailinglisten zu einer Bcc- oder Cc-Liste hinzugefügt werden, können wir uns saubere Abmeldelinks pro Benutzer leisten.
Was denkst du dazu? Was ist mit der einfachen Änderung, discourse_topic_100/23/7333 zu verwenden, z. B. (topic_id, post_number, user_id) als eindeutigen Bezeichner für die E-Mail? Es ist sicherlich eine eindeutige Nutzlast und wir können uns leicht darauf beziehen, wenn wir E-Mails für einen Benutzer generieren.
By Martin Brennan via Discourse Meta at 26Jul2022 00:27:
[quote=“Cameron Simpson, post:11, topic:233499,
username:cameron-simpson”]
Mutt probably ignores the References
because it is a mail reader, and References originates in USENET news.
Maybe Thunderbird is using the references or augumenting the in-reply-to
with references information.
You only need to consult one of In=-Reply-To or References to do
threading; the former comes from email and the latter from USENET.
You’re supporting both (which is great!) so we need to make them
consistent.
[/quote]
This is also super interesting. I believe (without examining the source) Thunderbird does do that, and likely the Gmail UI as well since it does the same thing.
I think mutt will use both, but probably just In-Reply-To if present, falling back to References. I’d need to check the source.
With References you do at least know the full chain to the OP; with In-Reply-To you more or less need the antecedant messages around to
stitch things together. For mailing lists I usually keep the whole
thread locally until it’s done anyway, and I expect that is common.
We do seem to be doing this but I guess not consistently? Basically we need to make sure that:
TODO #1 - If a post has an associated IncomingEmail record, we always use that Message-ID when sending email.
Yes. This is why I was thinking it might be sanest to have an explicit
field for the message-id, and to fill it in once. Then use that from
then on always, regardless of any changes to the process in which the
message-id is manufactured in the code later.
TODO #2 - Do not use a References when sending out emails related to the OP of the topic .
Yes. The OP has no antecedant, so there’s no References or In-Reply-To.
@cameron-simpson one question though – if the OP was created via an
inbound email, would we use that Message-ID in References for the
OP or still exclude it?
Still exclude. But use it as the persistent message-id for the OP.
So a message authored by email (OP or reply) gets its message-id from
the email. One authored on the web gets one when the user presses
Submit, generated by Discourse. From then on, that’s the message-id,
however created.
[quote=“Cameron Simpson, post:11, topic:233499,
username:cameron-simpson”]
You can just drop the sender_user_id and receiver_user_id from the
message-id field and get a single unique id which every receiver sees.
The uniqueness constraint is the post itself, not the individual
email-level “message” object.
[/quote]
This is interesting, I thought every recipient of the email had to have a unique Message-ID?
No. The message-id identifies the “message”. Not the individual copy. I
might post to the forum and CC someone directly. If that someone gets a
copy direct from me and also via the forum, they should have the same
message-id.
In fact I believe this is why we went down the path of adding
uniqueness to each recipient’s Message-ID, to avoid spam behaviours,
looking back on our internal topic. Perhaps @supermathie , who is on
our infra team and was doing a bunch of testing with email earlier in
the year, could weigh in here too?
Maybe. But on that face of it, threading is indeed broken. Certainly
sending the same message to many people should have the same message-id,
and generally, as a forwarder (email->discourse->email-recipients)
discourse shoud not be modifying the message-ids.
What you are saying is that it’s more that the post should be the thing determining a single Message-ID for all recipients. So perhaps we just generate one for each post that generates an email?
Every post should have one stable unique message-id for use in the email
side. If the post originated from an email, that original message-id
should be used. Otherwise (via the web interface) Discourse should be
generating a message-id and storing it with the post.
Then we could also move the IncomingEmail.message_id to here as well.
Sure. Having a distinct set of fields (message-id seems enough)
containing the email-side state should do it.
Tentatively, the change we would need to make is:
TODO #3 - **Add a outbound_message_id to the Post table. Generate
it once when an email is first sent in relation to the post.
If you got the post from an email, you should be using that, not
generating a new one.
Use if for subsequent References and In-Reply-To headers. Set its
value when a post is created from an IncomingEmail.
Yes. To the message-id from the email.
Format should be topic/:topic_id/:post_id/:random_alphanumeric_string@host e.g. topic/233499/33545/gvy8475y7c45y87554c@meta.discourse.org**
For ones you generate yourselves, this looks good to me.
After this change my first example would become this:
But note: the message-id only needs to be stable and unique. If the topic/:topid_id/:post_id@host is stable and will never be regenerated,
that will do. But if you’re concerned about that (eg db restores or
migrations or imports bringing those same numbers) then the random
string will make it robust against collision.
Note that the message-id left part is dot-atom-text, defined here:
which is alphas and digits and a limited set of punctuation characters
(which includes “/”).
Note the angle brackets. The message-id is formally the bit between the
angle brackets, and the angle brackets are mandatory. Syntax here:
With the consideration also that the OP does not have special handling, it will no longer be in the format topic/:topic_id@hostname.
Sounds good.
TODO #4 - Ensure that correct In-Reply-To and References headers are generated based on PostReply records and the new outbound_message_id column on the Post table
Thanks.
I think we have some consideration for this, I will double-check.
+1
It definitely seems that way
Can you confirm the TODOs here sound reasonable Cameron?
They seem correct to me.
It really doesn’t seem like much now that I look at it. I also wonder,
when I get to this work would you be open to joining a testing
Discourse instance with me that will have the WIP changes deployed to
it so we can email back and forth and test that things are working
correctly? I will of course do testing of my own before I involve you.
Certainly. Happy to help in whatever way.
If not, that’s fine too – I have Thunderbird and will be setting up mutt and I can test it all out there
Ich denke, Sie können immer noch eindeutige Nachrichten mit derselben message-id senden, selbst mit kleinen Unterschieden wie diesem.
Gewöhnliche Mailinglisten tun dies mehr oder weniger ständig. Zumindest geschieht immer eine gewisse Manipulation von Headern. Aber auch der Nachrichtenkörper wird manchmal geändert. Ein krasses Beispiel ist python-list, das Nicht-Text-Anhänge verwirft. Die Nachricht wird jedoch mit derselben message-id weitergeleitet. Und fast alle Listen fügen unten einen Zusatz hinzu, zum Beispiel einen Link zur Admin-Seite der Liste oder einen Abmeldelink. Das war nicht in der Nachricht, als sie ankam.
Und es gab lange Diskussionen über die Inhaltsverschlüsselung, die sich darum drehen, was von einer Signatur abgedeckt werden sollte.
Daher wäre es für mich völlig in Ordnung, wenn Sie Ihren empfängerspezifischen Abmeldelink hinzufügen und die ursprüngliche message-id beibehalten. Die Vorteile überwiegen den Verlust des Threadings bei weitem, wenn Sie jeder Nachrichtenkopie eine individuelle message-id geben würden.
Betrachten Sie wieder den E-Mail-Benutzer. Ich kann auf eine Diskursnachricht antworten und einen CC an eine interessierte externe Person hinzufügen. Vielleicht erhält diese eine Kopie von Diskurs, vielleicht auch nicht. Aber wenn sie eine erhält, sollte sie die Quell-message-id auch mit Ihrem zusätzlichen Zusatz darauf haben. Andernfalls hat sie 2 Kopien meiner Nachricht, aber ihr Mail-System weiß nicht, dass es Kopien derselben Nachricht sind. Das führt zu Problemen.
Kurz gesagt: Ich glaube nicht, dass Ihr sehr kleiner zusätzlicher Abmeldetext separate message-ids rechtfertigt. Behalten Sie nur die eine.
Entschuldigung, ich bin gerade erst auf dem Laufenden, hier sind einige Gedanken, von denen einige bereits angesprochen wurden…
Die Schwierigkeit hierbei ist, dass das, was von Discourse ausgesendet wird, eine andere Nachricht ist als die eingehende. Sie hat andere Metadaten (für diesen Zweck To/From/Reply-to/Unsubscribe/etc.) und einen anderen Body (er ist pro Benutzer angepasst (glaube ich? Passiert das im Mailinglistenmodus nicht?)).
Was genau ist die Nachricht? Wenn man 5322 als Evangelium betrachtet:
Eine Nachricht besteht aus Header-Feldern, optional gefolgt von einem Nachrichtentext.
Das Feld „Message-ID:“ liefert eine eindeutige Nachrichten-ID, die sich auf eine bestimmte Version einer bestimmten Nachricht bezieht.
[Hervorhebung von mir]
Es ist diese „bestimmte Version“, die mich denken lässt, dass es unangemessen wäre, eine eingehende Nachricht mit einer anderen Message-ID erneut zu senden. Wenn Sie jedoch Ihren Standpunkt von Discourse als „Forum-Software“ zu Discourse als „Mailinglisten-Software“ ändern, dann ergibt es irgendwie Sinn, dies zu tun, daher verstehe ich, woher Sie kommen. 5322 besagt auch:
Es gibt viele Fälle, in denen Nachrichten „geändert“ werden, aber diese Änderungen stellen keine neue Instanziierung dieser Nachricht dar, und daher erhält die Nachricht keine neue Nachrichten-ID. Zum Beispiel werden beim Einbringen von Nachrichten in das Transportsystem oft zusätzliche Header-Felder wie Trace-Felder (beschrieben in Abschnitt 3.6.7)
und Resent-Felder (beschrieben in Abschnitt 3.6.6) vorangestellt. Das Hinzufügen solcher Header-Felder ändert nicht die Identität der Nachricht, und daher wird das ursprüngliche
„Message-ID:“-Feld beibehalten. In allen Fällen bestimmt die Bedeutung, die der Absender der Nachricht vermitteln möchte (d. h. ob es sich um dieselbe
Nachricht oder eine andere Nachricht handelt), ob das
„Message-ID:“-Feld geändert wird oder nicht, nicht irgendein bestimmter syntaktischer Unterschied, der
in der Nachricht erscheint (oder nicht erscheint).
Ich nehme an, es kommt darauf an, ändert sich der Absender der Nachricht, wenn Discourse sie versendet?
Vielleicht sollten wir Resent-Message-ID und ähnliche verwenden?
Es war schon immer da, bis zurück zu 822. Aber wie Sie später sagen, ja, es wurde aktualisiert.
5322 spricht auch direkt über die Art und Weise, wie Discourse und Github es verwenden:
Das Feld „In-Reply-To:“ kann verwendet werden, um die Nachricht (oder Nachrichten) zu identifizieren, auf die die neue Nachricht eine Antwort ist, während das Feld „References:“ verwendet werden kann, um einen Gesprächs „Thread“ zu identifizieren.
Möglicherweise leicht falsch, wahrscheinlich aufgrund des Fehlens einer geeigneten „Thread-Kennung“-Header. Aber diese Interpretation ist möglicherweise nicht das, was die RFC-Autoren beabsichtigt haben… sie befasst sich nicht mit Nachrichten mit „References“, aber ohne „In-Reply-To“.
Der knifflige Teil daran ist, dass wir nicht eine E-Mail versenden, sondern N - eine pro Empfänger - damit deren individuelle Metadaten (Abmelden usw.) korrekt sind.
Und ja, ich habe während der Tests starke Anzeichen dafür gesehen, dass die Spam-Bestimmung an eine Message-ID gebunden wäre. Wenn sie später wieder gesehen wurde (derselbe Benutzer oder ein anderer Benutzer), wäre sie viel wahrscheinlicher als Spam markiert worden.
Die Vorteile hierbei sind, fairerweise gesagt, vollständig auf das korrekte Threading von E-Mails in bestimmten E-Mail-Clients ausgerichtet, auf Kosten der Zustellbarkeit.
Das aktuelle topic/#{topic_id}/#{post_id}.s#{sender_user_id}r#{receiver_user_id} macht es zumindest konsistent für einen Benutzer in seinem Posteingang. Die Annahme
Mein größtes Anliegen ist die Zustellbarkeit – es ist schon schwer genug, E-Mails zuzustellen, wenn die großen Anbieter keine Sichtbarkeit haben.
Aber ich sehe ein starkes Argument dafür, Discourse im Mailinglistenmodus mehr wie eine Mailinglisten-Software zu verhalten. @martin Ich glaube, wir passen den Nachrichtentext im Mailinglistenmodus nicht an? Glauben Sie, dass es sinnvoll ist, einen strengeren Ansatz bezüglich der Beibehaltung und Wiederverwendung von Message-IDs im Mailinglistenmodus zu verfolgen?
Ich möchte hier nicht in eine Situation geraten, in der Perfektion das Gute genug verhindert.
Wir verwenden jetzt „zufällige Suffixe“ in Nachrichten, und das verursacht unbestreitbar Probleme.
Wir haben 3 Optionen zur Auswahl:
Zufällige Nachrichten-IDs, auf die nicht zurückverwiesen werden kann
Nachrichten-IDs stabil pro Thema/Beitrag/Benutzer
Nachrichten-IDs stabil pro Thema/Beitrags-Paar
Wir befinden uns derzeit in Planet (1), was verheerende Auswirkungen hat.
Ich befürchte, dass wir zwischen (2) und (3) eine Entscheidungsfindung erreichen können.
Vielleicht beginnen wir einfach mit (2) und erkennen an, dass das Hinzufügen zusätzlicher Kopien zu einer E-Mail von Discourse unerwartetes Verhalten verursachen kann, und hören zumindest auf, den Großteil der Probleme hier zu verursachen?
ah! Ich dachte, wir würden bereits Folgendes tun: topic/#{topic_id}/#{post_id}.s#{sender_user_id}r#{receiver_user_id}
Ich wäre geneigt, im Interesse der Abwägung von E-Mail-Einzigartigkeit und Zustellbarkeit gegenüber den Bedenken des Mailinglistenmodus, (2) für Mailinglistenmodus deaktiviert und (3) für Mailinglistenmodus aktiviert zu tun.
Ebenso wäre ich bei der References-Kopfzeile geneigt, sie für Beitrag Nr. 1 in einem Thema abwesend zu haben und sie auf das Thema (also topic/#{topic_id}) und den Beitrag, auf den geantwortet wird, falls vorhanden, verweisen zu lassen.
Ich habe mir das heute Morgen tatsächlich angesehen und überraschenderweise funktioniert das Threading in einer einheitlichen Ansicht in Thunderbird in den meisten Fällen, und ich denke, der 
I’ve actually been looking into this this morning
