Entschuldigen Sie im Voraus für den Tonfall unten. Ich klinge ein wenig verärgert, weil ich es auch bin.
Von Michael Brown via Discourse Meta am 27. Juli 2022, 14:06 Uhr:
Entschuldigung, ich bin gerade erst auf dem neuesten Stand, hier sind einige Gedanken, von denen einige bereits angesprochen wurden…
Die Schwierigkeit hierbei ist, dass das, was aus Discourse herausgesendet wird, eine andere Nachricht ist als die eingehende. Sie hat andere Metadaten (für diesen Zweck: An/Von/Antworten-an/Abmelden/usw.) und einen anderen Body (sie ist pro Benutzer angepasst (glaube ich? Passiert das im Mailinglisten-Modus 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 “Forensoftware” zu Discourse als “Mailinglisten-Software” ändern, dann ergibt es irgendwie Sinn, dies zu tun, daher verstehe ich, woher Sie kommen.
Nun, leider hängt dies von einer übermäßig wörtlichen Auslegung ab, vielleicht von einer Auslegung, die keinen Kontext hat.
Jede E-Mail-Nachricht wird in ihren Headern modifiziert, wenn das Mailsystem sie weiterleitet. Wenn nichts anderes, werden Received:-Header bei jedem Schritt hinzugefügt, und mehrere Systeme fügen verschiedene Header hinzu, die Spamfilterergebnisse und Signaturen anzeigen. Keines davon löst eine Änderung der Message-ID aus, und tatsächlich würde dies die Message-ID völlig funktionsunfähig machen.
Bezüglich des Inhalts wird, wie bereits erwähnt, fast jede Mailingliste dem Textkörper Inhalt hinzufügen, normalerweise eine Fußzeile mit einem Link zur Admin-Seite der Liste oder einem Abmelde-Link. Auch das löst keine Änderung der Message-ID aus.
Tatsächlich ändert fast nichts, das eine Nachricht weiterleitet, die Message-ID. Denn das würde das Threading und die Duplikaterkennung für Endbenutzer-Clients brechen.
Ich sehe, Sie zitieren weiter, was ich gerade zitieren wollte 
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 würde die Nachricht keine neue Nachrichten-ID erhalten. Zum Beispiel werden beim Einführen 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. Die Hinzufügung 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 dies dieselbe Nachricht oder eine andere Nachricht ist), ob sich das “Message-ID:”-Feld ändert oder nicht, nicht irgendein bestimmter syntaktischer Unterschied, der in der Nachricht erscheint (oder nicht erscheint).
Ich nehme an, es kommt darauf an, ob sich der Absender der Nachricht ändert, wenn Discourse sie versendet?
Ich glaube, Sie haben hier etwas falsch gelesen. Lassen Sie mich hervorheben:
In allen Fällen bestimmt die Bedeutung, die der Absender der Nachricht
möchte (d. h. ob dies dieselbe Nachricht oder eine andere Nachricht ist), ob sich das “Message-ID:”-Feld ändert
Der Absender ist der Autor, nicht ein MTA wie Discourse.
Wenn ich per E-Mail an Discourse poste, möchte ich, dass meine Nachricht die Leser so erreicht, wie sie ist, semantisch gesehen. Jegliche Zusätze wie Abmelde-Links ändern nicht die Semantik dessen, was ich in meiner Nachricht gesagt habe.
Es ist immer noch dieselbe Nachricht.
Vielleicht sollten wir Resent-Message-ID und Freunde verwenden?
Absolut nicht. Sie sind für einen Benutzer, der eine Nachricht erneut einreicht. Zum Beispiel, wenn ich eine Nachricht an jemand anderen weitergeleitet habe. Sie sind nicht für Mail-Relays (wie Listen und Discourse).
Es war schon immer da, bis zurück zu 822. Aber wie Sie später sagen, ja, es wurde aktualisiert.
Autsch. Ich dachte, es wäre zu dieser Zeit nur USENET. Ich korrigiere mich.
5322 spricht auch direkt darüber, 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 unsachgemäß, wahrscheinlich aufgrund des Fehlens eines geeigneten “Thread Identifier”-Headers. Aber diese Interpretation ist vielleicht nicht das, was die RFC-Autoren beabsichtigt haben… sie befasst sich nicht mit Nachrichten mit “References”, aber ohne “In-Reply-To”.
Es sagt mir, dass die beiden Felder dieselbe Information abdecken:
Referenceszeigt einen linearen (normalerweise) Thread zurück zum OPIn-Reply-Tozeigt das übergeordnete Element und impliziert denselben Thread insgesamt mit den vorherigen Nachrichten zurück zum OP
Das knifflige daran ist, dass wir nicht eine E-Mail versenden, sondern N - eine pro Empfänger - damit deren individuelle Metadaten (Abmelden usw.) korrekt sind.
Das ist nicht knifflig. Die Bedeutung der Nachrichten ist dieselbe, die Anpassungen sind geringfügig und semantisch irrelevant. Sie rechtfertigen keine neuen oder unterschiedlichen Message-IDs.
Und ja, ich habe während der Tests starke Hinweise darauf gesehen, dass die Spam-Bestimmung an eine Message-ID gebunden wäre. Wenn sie später wieder gesehen würde (derselbe Benutzer oder ein anderer Benutzer), würde sie viel wahrscheinlicher als Spam markiert werden.
Können Sie einige dieser Fälle zeigen. Denn Message-IDs ermöglichen die Deduplizierung am Ende des Benutzers. Und bedenken Sie, dass viele “Anti-Spam”-Maßnahmen fehlgeleiteter Müll sind. Die Anzahl der Dinge, die ich aus völlig fadenscheinigen Gründen als potenziellen Spam abgelehnt habe… das E-Mail-System zu brechen, um fehlerhafte Spam-Fehlfilterung zu umgehen, ist eine schlechte Wahl.
Bis heute sende ich nie CC an Personen mit GMail-Adressen, weil die Spamfilterung von GMail mich kennt und Dinge auf dem Boden fallen lässt. Wenn ich nur an die Liste sende, bekommen sie es. Wenn ich die GMail-Adresse CC’e, wird sie (a) als Spam markiert und (b) dann wird auch die Mailinglisten-Nachricht als Spam markiert (dieselbe Message-ID!). Der Endbenutzer sieht meine Nachricht nicht. Diese Logik ist völlig fadenscheinig und nicht reparierbar.
Die Vorteile hierbei sind, um fair zu sein, vollständig auf das korrekte Threading von E-Mails in bestimmten E-Mail-Clients ausgerichtet, auf Kosten der Zustellbarkeit.
Seufz. An alle E-Mail-Clients. Und ein Hauptgrund, warum Leute in Pythonland sagen, dass sie einfach nicht zu Discourse wechseln werden, ist, dass das Threading auf der E-Mail-Seite kaputt ist. Viele Leute benutzen keine Foren, weil jedes Forum von ihnen verlangt, dass sie es besuchen. E-Mails kommen zu ihnen, sie können ihren bevorzugten Reader und ihren bevorzugten Editor verwenden, und das Threading ermöglicht es den Leuten, den Gesprächsfluss klar zu sehen. Wenn es funktioniert.
Die 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 es von den großen Anbietern keine Sichtbarkeit gibt.
Ich möchte Beweise sehen. Mailinglisten machen das weltweit korrekt. Discourse bricht dies definitiv und objektiv. Ich versuche, es zu reparieren.
Lassen Sie mich die beiden grundlegenden Probleme hier wiederholen:
- Der OP
In-Reply-ToundReferenceszitieren eine fiktive “Pre-OP”
“topic” Message-ID, sodass kein E-Mail-Benutzer einen Thread mit einer startenden Nachricht (dem OP) hat - alles, einschließlich des OP, sieht wie eine Nachverfolgung aus. - Die über Discourse empfangenen E-Mails und die direkt empfangenen E-Mails, z. B. über CC, haben unterschiedliche Message-IDs, obwohl sie semantisch gesehen dieselbe Nachricht sind; dies bricht das Threading und die Deduplizierung.
Aber ich sehe ein starkes Argument dafür, Discourse im Mailinglisten-Modus mehr wie eine Mailinglisten-Software zu verhalten. @martin Ich glaube, wir passen den Nachrichtentext im Mailinglisten-Modus nicht an? Glauben Sie, es ist sinnvoll, einen strengeren Ansatz beim Beibehalten und Wiederverwenden von Message-IDs im Mailinglisten-Modus zu verfolgen?
Es gibt Leute in Pythonland, die den “Mailinglisten-Modus” als zu viel des Guten empfanden. Sie möchten E-Mails für gezielte Themen erhalten, aber nicht alles. Die Handhabung der Message-ID sollte für alle E-Mail-Seiten gleich sein.
Ich bin ein “Mailinglisten-Modus”-Person auf discuss.python.org. Aber ich habe es hier (discourse.org) aktiviert und es _sofort wieder deaktiviert. Ich brauche hier einen gezielten Modus.
