Sul sito discuss python org stiamo discutendo dell’aspetto email di Discourse. La lamentela più grande è la mancanza di threading. Ho fatto qualche ricerca negli header e sembra che:
l’header Message-ID sia almeno univoco
gli header Reply-To e Referencesnon si riferiscano ai Message-ID di altri messaggi, tanto meno all’ID del messaggio a cui si sta rispondendo
invece si riferiscano a un ID messaggio fittizio basato sul numero dell’argomento
Ciò significa che gli utenti che utilizzano l’email vedono (a) discussioni completamente piatte e non thread e (b) il messaggio radice sembra mancante, perché gli header In-Reply-To e References si riferiscono a un ID messaggio che in realtà non appare mai in nessun messaggio.
Questo è grave e viola la RFC 5322. E rende l’esperienza via email molto peggiore di quanto potrebbe facilmente essere.
Ad esempio, c’è un thread lì la cui prima messaggio ha questi header:
Ancora, un Message-ID ok, ma In-Reply-To e References completamente insensati.
Questo dovrebbe essere facile da correggere. Il primo messaggio non dovrebbe avere né header In-Reply-To né References. Il secondo messaggio dovrebbe avere l’Message-ID del primo messaggio negli header In-Reply-To e References.
Si prega di consultare la sezione 3.6.4 della RFC5322 per i dettagli:
Così come stanno le cose, gli utenti di posta elettronica vedono discussioni piatte e non strutturate. Con queste correzioni, possono avere una visualizzazione thread sensata e facile da seguire.
Sto solo dando un’occhiata alla differenza tra HEAD e quella correzione.
Mi sembra che current imposti ancora sempre References, anche se non c’è un antecedente - topic_canonical_reference_id viene usato come fallback. Penso ancora che sia sbagliato, perché non c’è nessun messaggio email con quell’id.
In-Reply-To è un po’ più corretto, in quanto viene impostato solo se post.post_number!=1, ma fa ancora fallback a topic_canonical_reference_id:
il fallback dovrebbe essere il Message-ID del post #1 se non ci sono referenced_post_message_ids, e nontopic_canonical_reference_id
qualcosa nel codice receipt-of-reply-emails deve far cadere l’header In-Reply-To dei messaggi di risposta, perché avrebbero dovuto popolare correttamente l’array referenced_post_message_ids (“lista”? Sono nuovo a Ruby)
Cameron, grazie per aver aperto questo argomento di discussione e per aver fornito molti dettagli nei tuoi post. Sono responsabile di questo “vaso di Pandora”, da questi due commit:
Siamo consapevoli di alcuni problemi relativi al threading da un po’ di tempo nei client di posta elettronica come Thunderbird, ma non rappresentava un gran numero di consumatori di threading via email da Discourse, quindi è stato rimandato. Ora che questo viene alla luce, dobbiamo dedicare del tempo a riesaminare il problema e a lavorare su una soluzione.
È interessante notare che abbiamo aggiunto questa intestazione References alla prima email inviata e a tutte quelle successive al momento, poiché fa funzionare correttamente il threading in Gmail, ma concordo sul fatto che non sia l’ideale e stia probabilmente causando i problemi di threading, insieme al mancato utilizzo del Message-ID originale nelle intestazioni In-Reply-To e References delle email successive.
Ti prego di avere pazienza mentre esamino vecchie discussioni e il codice e lavoro su questo. Nel frattempo, sei a conoscenza di altri client di posta elettronica che vengono utilizzati e stanno riscontrando problemi? Ad esempio, so che questo è un problema in Thunderbird, ma in altri? Grazie.
Ci dispiace, ma il tuo messaggio email a
["incoming+8349bd9eb1f2b582df4f32dbe85c3363@meta.discoursemail.com"]
(intitolato Re: [Discourse Meta] [bug] I messaggi email di Discourse sono
erroneamente in thread) non ha funzionato.
Motivo:
Spiacenti, i nuovi utenti possono inserire solo 2 link in un post.
Se riesci a correggere il problema, riprova.
Lo inserirò nel forum dove potrò recuperarlo e revisionarlo…
Cameron, grazie per aver aperto questo argomento di discussione e per aver fornito
molti dettagli nei tuoi post. Sono responsabile di questo vaso di Pandora,
da questi due commit:
3b13f1146b2a406238c50d6b45bc9aa721094f46
Questo sembra a posto. Salva questo id con il record del database in modo che le risposte in arrivo possano essere collegate al messaggio del forum antecedente?
Inoltre, vuoi che verifichi che il suffisso sia sintatticamente legale per RFC5322, in termini di caratteri consentiti?
82cb67e67b83c444f068fd6b3006d8396803454f
Questo secondo commit sembra affrontare un altro problema che abbiamo riscontrato: se un post proviene da un’e-mail, il message-id in uscita inviato agli utenti di posta elettronica non è il message-id del messaggio sorgente dell’autore. Ciò si traduce in due messaggi diversi dal punto di vista di un client di posta elettronica e probabilmente interrompe le risposte fatte all’originale anziché alla copia inviata dal forum. Ad esempio:
A: il forum
CC: uno dei partecipanti
Il partecipante riceverà (beh, forse) una copia dal forum e una copia diretta dall’autore, e questi saranno messaggi distinti dalla loro parte perché avranno message-id diversi.
Stavo per creare un secondo bug report su questo problema dopo aver risolto il problema degli header in-reply-to e references, che è molto più importante.
Siamo consapevoli di alcuni problemi relativi al threading da un po’ di tempo nei client di posta elettronica come Thunderbird, ma non ha rappresentato un gran numero di consumatori di threading via email da Discourse, quindi è stato rimandato, ma ora che questo sta venendo alla luce dobbiamo dedicare del tempo a riesaminare il problema e lavorare su una soluzione.
Io e diversi altri usiamo mutt. Sono felice di fare tutto il necessario per aiutare nel debug e nella revisione del codice. Sono stato anche un sysadmin di posta per un sacco di tempo in vite precedenti.
[quote=“Cameron Simpson, post:1, topic:233499,
username:cameron-simpson”]
È il primo messaggio. Non dovrebbe avere un header References, perché non c’è nessun messaggio da nessuna parte con quell’id.
[/quote]
Interessante, abbiamo aggiunto questo header References alla prima email inviata e a tutte le successive al momento poiché rende il threading funzionante correttamente in Gmail,
Penso che un header References corretto (assente nel primo post, come in-reply-to nelle risposte) dovrebbe funzionare anche. Ma GMail ha un rapporto piuttosto lasco con gli standard di posta elettronica a volte. Ho un accordo con gmail; posso fare anche del debug lì. E in linea di principio possiamo usare questa stessa discussione come banco di prova, forse.
ma concordo sul fatto che non sia l’ideale e che probabilmente stia causando i problemi di threading
insieme al mancato utilizzo del Message-ID originale nei successivi header In-Reply-To e References dell’email.
Per favore, abbiate pazienza mentre esamino vecchie discussioni e il codice e lavoro su questo.
Nessun problema.
Nel frattempo, sei a conoscenza di altri client di posta elettronica che vengono
utilizzati e stanno riscontrando problemi? Ad esempio, so che questo è un
problema in Thunderbird, ma in altri? Grazie.
Sicuramente mutt. Almeno con mutt è molto facile vedere gli header e anche vedere la catena dell’albero delle risposte, che è spesso oscurata in altri client.
Il threading della posta è interamente definito dagli header Message-ID e In-Reply-To. L’header References è iniziato con USENET per i follow-up, e supportava (lì) più message-id; l’In-Reply-To supporta solo uno. Sembra che References sia ora presente anche in RFC5322, e ne verificherò la semantica.
Va bene, è una cosa piuttosto importante, ti prego di avere pazienza. Innanzitutto, grazie per un’altra risposta dettagliata e per l’offerta di debug/revisione, è molto utile In realtà ci stavo lavorando stamattina e, sorprendentemente, l’organizzazione in thread in una vista unificata funziona in Thunderbird per la maggior parte dei casi, e penso che l’header References che punta costantemente all’OP aiuti in questo (ad esempio, l’argomento Reference in questa catena che è sempre presente è \u003ctopic/53@discoursehosted.martin-brennan.com\u003e).
Il caso in cui l’organizzazione in thread non funziona come previsto è:
Viene creato un post all’interno di Discourse e viene inviata un’email a coloro che seguono l’argomento poi
Qualcun altro risponde a quel post e viene inviata un’email a coloro che seguono l’argomento
Nel caso della seconda email, ottiene un header In-Reply-To e References errato poiché ne genera uno su questa riga discourse/lib/email/sender.rb at 98bacbd2c6b9fe57167cd32af5eb4839b4a5d1f6 · discourse/discourse · GitHub piuttosto che utilizzarne uno esistente. Dovrebbe utilizzare il Message-ID per l’email inviata per prima. Nello screenshot, è qui che i messaggi che seguono questo schema dovrebbero essere posizionati:
La risposta è: dipende. Se un post viene creato in Discourse da un’email in arrivo, come questo tuo, utilizziamo il Message-ID originale in arrivo di quel post quando qualcuno risponde ad esso per gli header In-Reply-To e References come da:
Altrimenti stiamo solo utilizzando il riferimento all’OP dell’argomento e generando un nuovo riferimento, il che ovviamente è ciò che sta causando tutti i problemi. In tutti i casi generiamo un nuovo Message-ID ogni volta che viene inviata un’email in uscita, il che sembra corretto e in linea con altri client di posta.
Penso di aver capito cosa intendi, va così:
cameron invia un’email a Discourse da mutt che ottiene Message-ID: 74398756983476983@mail.com
Discourse crea un post e memorizza il Message-ID contro il post con un record IncomingEmail
johndoe sta seguendo l’argomento, quindi gli viene inviata un’email da Discourse con un Message-ID: topic/222/44@discourse.com e nessun riferimento all’Message-ID originale 74398756983476983@mail.com
Corretto, dovremmo semplicemente “passare” quel Message-ID a coloro che seguono l’argomento invece di generarne uno nostro dato che è già univoco? Cosa succede poi nel client di posta di johndoe se cameron lo ha anche messo in CC su quel messaggio in uscita originale? Questo sembra un problema separato, quindi sarebbe bene aprire un altro argomento di bug per esso.
Configurerò un client mutt localmente per vedere cosa stai riscontrando anche tu, non ho mai testato questa funzionalità in un client basato su testo (solo Gmail e Thunderbird) quindi sono ansioso di vedere come appare comunque.
La mia idea per affrontare questi problemi stamattina è stata quella di eliminare i suffissi generati casualmente quando inviamo gli header Message-ID nelle email e invece passare a uno schema in cui utilizziamo l’user_id sia dell’utente che invia che di quello che riceve. Il vantaggio di questo è che non è necessario memorizzare il Message-ID da nessuna parte (a parte quando un’email in arrivo crea un post) e quindi gli header References e In-Reply-To saranno sempre coerenti. Lascia che ti dia un esempio. Supponiamo di avere questi utenti:
martin - user_id 25
cameron - user_id 44
sam - user_id 78
bob - user_id 999
E poi abbiamo questo argomento, topic_id 233499, con post a partire da post_id 100 come OP. Il formato diventerebbe topic/#{topic_id}/#{post_id}.s#{sender_user_id}r#{receiver_user_id}. L’ordine delle operazioni sarebbe il seguente:
bob crea il post 103 nell’argomento, non in risposta a nessuno (notare che i References qui includono il Message-ID inviato a entrambi gli utenti per l’email dell’OP)
bob - risposta nell’argomento non a un post specifico
INVIATO → a: discourse, RE: post di bob
casella di posta di sam
martin - OP dell’argomento
cameron - secondo post
INVIATO → a: discourse, RE: secondo post
bob - risposta nell’argomento non a un post specifico
Penso che sia corretto, puoi dare un’occhiata a ciò che ho scritto in questi header e verificare che sia quello che ti aspetteresti da questo scenario? L’unica cosa di cui sono un po’ insicuro è se ho coperto tutti i References, e ovviamente testerei questo su un set di email live in un branch di sviluppo prima di implementarlo. Non ho ancora testato nulla in mutt.
Come nota a margine, ho anche esaminato cosa fa GitHub con le sue email di notifica e ho notato che fanno una cosa simile dove hanno un Reference onnipresente (discourse/discourse/pull/252@github.com) che viene utilizzato in tutte le email relative a quell’“argomento” che in questo caso è una pull request di GitHub:
Di Martin Brennan tramite Discourse Meta il 22 lug 2022 alle 06:34:
Okay, questa è una questione piuttosto grande, per favore abbiate pazienza. Innanzitutto, grazie per
un’altra risposta dettagliata e per l’offerta di debug/revisione, è davvero
utile Ho effettivamente iniziato a indagare su questo stamattina e,
sorprendentemente, la visualizzazione a thread in una vista unificata funziona in Thunderbird
per la maggior parte dei casi, e penso che l’intestazione References che punta
costantemente all’OP aiuti in questo (ad esempio il Reference del topic
in questa catena, che è sempre presente, è <topic/53@discoursehosted.martin-brennan.com>.
Ho appena rilettto attentamente la sezione 3.6.4 della RFC5322. Si è evoluta rispetto
alle versioni precedenti (822 e 2822) e ha fuso le intestazioni email In-Reply-To,
le intestazioni USENET References e la citazione moderna di più di un messaggio precedente.
La breve sintesi:
L’Message-ID è un identificatore persistente unico per un messaggio.
L’In-Reply-To contiene tutti gli ID dei messaggi a cui questo messaggio
risponde direttamente; quindi, se rispondo a una coppia di messaggi, conterrà
quei 2 ID.
Le References sono una catena di risposta degli ID dei messaggi antecedenti dall’
OP al messaggio precedente. Quindi, in effetti, dovrebbero sempre iniziare con
l’ID del messaggio OP.
Quindi, per discussioni come questa, fingendo che le etichette siano ID dei messaggi:
È anche legale includere “reply1 reply2” nelle references (l’altra catena verso reply5),
ma la RFC raccomanda esplicitamente di non farlo perché alcuni client si aspettano che
le references siano una singola catena lineare di risposte, non qualche grafo diretto appiattito.
Quindi la mia raccomandazione per costruire le references è usare le references del
messaggio antecedente “primario” con l’ID del messaggio del messaggio antecedente primario
aggiunto. In questo modo si ottiene sempre una catena lineare nell’ordine corretto.
Interessante, sembra esserci qualche threading lì.
Ma notate: il post in alto ha una piccola freccia “è una risposta”. Anche se è
il post 1. Immagino sia a causa della voce “topic” nelle references, che fa
pensare a TB che ci fosse un messaggio precedente (il che, ovviamente, non è vero).
Nel mondo di mutt vediamo quasi nessun threading:
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
Questo perché ogni In-Reply-To punta direttamente al fittizio ID del messaggio “topic”.
Mutt probabilmente ignora le References perché è un lettore di posta e References
ha origine nelle news USENET. Forse Thunderbird sta usando le references o sta
arricchendo l’in-reply-to con informazioni dalle references.
Bisogna consultare solo una tra In-Reply-To o References per fare il threading;
la prima proviene dalla posta elettronica e la seconda da USENET. Voi supportate entrambe
(il che è ottimo!), quindi dobbiamo renderle coerenti.
(A parte: c’è anche una discussione sul mirror di USENET, perché diverse persone
che usano Python consumano le mailing list tramite un’interfaccia USENET. Di nuovo, un
argomento separato.)
[…]
La risposta è: dipende. Se un post viene creato in Discourse da un’email in arrivo, come questa tua, usiamo l’Message-ID originale dell’email in arrivo di quel post quando qualcuno risponde ad esso per le intestazioni In-Reply-To e References come da:
Altrimenti stiamo solo usando il riferimento OP del topic e generando semplicemente un nuovo riferimento, il che ovviamente sta causando tutti i problemi. In tutti i casi generiamo un nuovo Message-ID ogni volta che viene inviata un’email in uscita, il che sembra corretto e in linea con altri client di posta.
Purtroppo, non esattamente. Se sei l’origine del messaggio (cioè scritto in
Discourse), generare l’ID del messaggio va bene. Se non c’è un ID del messaggio
(illegale), generarne uno è una pratica standard (di solito fatta dagli MTA). Ma se
stai inoltrando un messaggio (scritto via email), l’ID del messaggio esistente
dovrebbe essere preservato.
A mio avviso dovresti fare tre cose:
avere un ID del messaggio stabile e non sostituire l’ID del messaggio di un
messaggio in arrivo
generare In-Reply-To corretto, che è facilmente calcolabile dai
messaggi(i) antecedente(i) immediati, cioè ID-del-messaggio-antecedente(i)
generare References corretto, che è facilmente calcolabile come
References-antecedente + ID-del-messaggio-antecedente
Per il punto 1, guardando il codice che citi, probabilmente vorresti che l’ID del messaggio
di posta fosse (sintassi Python, scusa):
def message_id(post):
return post.incoming_email.message_id or discourse_message_id(post)
cioè, l’ID del messaggio di posta del post se proviene da un’email, altrimenti
l’ID del messaggio di Discourse usando qualcosa come l’algoritmo che hai delineato
più avanti in questo messaggio: qualsiasi cosa (a) stabile e (b) sintatticamente valida.
Poi calcolare i campi In-Reply-To e References è una questione meccanica semplice
come nei punti 2 e 3.
Credo di capire cosa intendi, è così:
cameron invia un’email a Discourse da mutt che ottiene Message-ID: 74398756983476983@mail.com
Discourse crea un post e salva l’Message-ID associato al post con un record IncomingEmail
Corretto.
johndoe sta monitorando il topic, quindi riceve un’email da Discourse con un Message-ID: topic/222/44@discourse.com e nessun riferimento all’originale Message-ID: 74398756983476983@mail.com
No. Vuoi davvero passare attraverso IncomingEmail.message_id come Message-ID nell’email per johndoe. È lo stesso messaggio.
Suona corretto, che dovremmo semplicemente “passare” quell’Message-ID a chi monitora il topic invece di generarne uno nostro dato che è già unico? Cosa succede poi nel client di posta di johndoe se
cameron lo ha anche messo in CC su quel messaggio in uscita originale? Questo sembra un problema separato, quindi sarebbe buono aprire un altro topic per il bug.
Passandolo, il messaggio originale (cameron->cc:johndoe) e il messaggio inoltrato
da Discourse (cameron->Discourse->johndoe) hanno lo stesso ID del messaggio e lo stesso
contenuto. Il sistema di ricezione della posta li memorizza entrambi. Il lettore di posta
li vede entrambi e o li presenta entrambi o ne mantiene solo uno (questa è una decisione
politica del lettore di posta - mantenerne solo uno è comune). Dato che sono lo stesso
messaggio, in generale non importa quale venga mantenuto.
Se ignorassimo Discourse e considerassimo un messaggio che è una copia del messaggio
tramite la mailing list e anche tramite email diretta. Sono lo stesso messaggio, con lo
stesso ID del messaggio.
Imposterò un client mutt localmente per vedere cosa vedi anche tu; non ho mai testato questa funzionalità in un client basato su testo (solo Gmail e Thunderbird), quindi sono molto interessato a vedere come appare comunque.
Felice di aiutare con le impostazioni. Per la visualizzazione a thread devi impostare
l’ordinamento su threaded. Mutt è molto configurabile.
La mia linea di pensiero per affrontare questi problemi stamattina era sbarazzarmi
dei suffissi generati casualmente quando inviamo intestazioni Message-ID nelle email e invece passare a uno schema in cui usiamo l’user_id sia dell’utente mittente che di quello destinatario. Il vantaggio
di questo è che non c’è bisogno di memorizzare l’Message-ID da nessuna parte
(tranne quando un’email in arrivo crea un post) e quindi le intestazioni References
e In-Reply-To saranno sempre coerenti.
Sì, è molto meglio. Notando che l’ID del messaggio dell’email in arrivo
dovrebbe sovrascrivere l’ID del messaggio derivato da Discourse per l’email in uscita.
(La maggior parte dei sistemi di posta usa stringhe casuali perché non c’è un contesto
circostante come la struttura dei messaggi del topic Discourse; i messaggi sono
considerati singolarmente; ma l’unico requisito reale è l’unicità persistente.)
Lasciami fare un esempio. Diciamo che abbiamo questi utenti:
martin - user_id 25
cameron - user_id 44
sam - user_id 78
bob - user_id 999
E poi abbiamo questo topic, topic_id 233499, con post che iniziano da post_id 100 come OP. Il formato diventerebbe topic/#{topic_id}/#{post_id}.s#{sender_user_id}r#{receiver_user_id}.
Non dovrebbe esserci un’intestazione References nell’OP. Non è
necessaria per il threading e in effetti finge che esista un “post 0”
che non esiste. Significa che ogni OP (a) sembra una risposta, cosa che non è,
e (b) sembra che ciò a cui risponde manchi dalla casella di posta del lettore.
Questo crea ID dei messaggi diversi per ogni copia in uscita dell’OP.
È sbagliato. Devono essere gli stessi. Supponiamo che sam metta in CC cameron
direttamente in una risposta. L’In-Reply-To citerà un ID del messaggio che cameron
non ha mai ricevuto.
Puoi semplicemente ometteresender_user_id e receiver_user_id dal campo
message-id e ottenere un singolo ID unico che ogni destinatario vede.
Il vincolo di unicità è il post stesso, non il singolo oggetto “messaggio” a livello di email.
Riguardo alle References, l’OP non dovrebbe averne. TB e tutto il resto
staranno bene. Se stanno facendo il threading usando References invece di In-Reply-To, le References nei messaggi di risposta sono sufficienti.
Ecco l’inizio di un thread di discussione di una mailing list 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
Ignora che ordino la mia posta dal più recente in alto. Vedi che non c’è freccia sul
post iniziale (in basso). Quel messaggio non ha References e
nessun In-Reply-To. Tutti gli altri hanno In-Reply-To (e possibilmente References, ma questa è una mailing list via email quindi non necessariamente; come ho
menzionato prima sono complementari.)
Se ripeto il mio esempio Discourse di prima:
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
Vedi che tutti hanno una freccia iniziale? Questo perché il client di posta
pensa che siano tutte risposte a un messaggio radice comune (e mancante),
che è a causa dell’ID del messaggio “topic” nell’intestazione References. Mentre il post 1 è in realtà il messaggio in basso mostrato sopra.
Sintesi:
il tuo piano è buono, a patto che tu rimuova mittente e destinatario dall’
ID del messaggio: sono inutili e in realtà il destinatario causerà problemi (il mittente è solo ridondante).
rimuovi il pseudo-ID del messaggio “topic” dalle References: inganna i
client di posta (incluso TB, anche se non è visivamente evidente)
cameron risponde via email
discourse riceve un’email con queste intestazioni da mutt:
Sì, ancora con la precisazione che non dovrebbe esserci un riferimento “topic”.
Come previsto, c’è un riferimento all’ID del messaggio OP. Anche se dovrebbe
essere lo stesso ID del messaggio che sam vede per l’OP.
discourse (come cameron, dall’email sopra) crea il post 101
sam riceve un’email da discourse con queste intestazioni:
E qui va storto. L’Message-ID dovrebbe essere 43585349859734@test.com dal campo .incoming_post.message_id.
(Bene, secondo me questo è post.message_id(), che restituisce post.incoming_post.message_id per un post generato da email e il tuo
generato da Discourse altrimenti).
Considera: compongo e invio la mia risposta con l’ID del messaggio 43585349859734@test.com. Per motivi di continuità, tengo una copia di quella
nella mia cartella locale, dove appare come una risposta all’OP. Idealmente
Discourse mi invia anche una copia del mio post (questa è un’impostazione politica
su molte mailing list), quindi ricevo anche la versione di Discourse. Dovrebbe
avere lo stesso ID del messaggio, perché è lo stesso messaggio, solo tramite un
diverso percorso.
Il messaggio di Discourse non è “in risposta a” il mio messaggio. È il mio
messaggio, solo inoltrato.
Questo effetto si propaga attraverso i tuoi esempi successivi. Il processo effettivo
dovrebbe essere più semplice di quanto l’abbia reso.
Pensala così. Se rispondo a un post da email, è effettivamente come se
stessi inviando un’email a sam (e agli altri) tramite Discourse. Discourse
inoltra il mio messaggio agli abbonati che ricevono email e,
“incidentalmente” ne mantiene una copia sul forum
Di passaggio, ho anche guardato cosa fa GitHub con le sue
email di notifica, e ho notato che fanno una cosa simile dove hanno un Reference sempre presente
(discourse/discourse/pull/252@github.com) che viene usato in tutte le
email relative a quel “topic” che in questo caso è una pull request di GitHub:
Hoo, GitHub. Che disastro le loro email per le issue
Tuttavia, nel loro scenario, la PR è l’OP. Quindi un riferimento diretto
alla pull è sensato. Si potrebbe usare l’ID del messaggio “topic” per il post 1,
a patto che non si usasse anche l’ID “topic/1”. Ma sembra poco utile: è uno sforzo
extra trattare il caso speciale del post 1: userei semplicemente “topic/1” io stesso.
Per aggiungere un po’ di complicazione. Per quanto ne so, un amministratore può spostare un post
o un topic. Non rompe questo schema di “generazione dell’ID del messaggio”, in
particolare se spostano solo un post? Sono dell’opinione che ogni post
dovrebbe avere un campo _message_id, riempito dal messaggio in arrivo (da email)
o generato (pubblicazione tramite Discourse). Allora sarebbe persistente, stabile e robusto
contro qualsiasi riordino dei post o cambiamenti di algoritmo.
Infine, c’è una piccola considerazione di sicurezza: dovresti ignorare l’
ID del messaggio dell’email in arrivo (e potenzialmente rimbalzare il messaggio) se afferma
l’ID del messaggio di un post esistente. Dato che, come autore, posso mettere
qualsiasi cosa io voglia in quell’intestazione Io opterei per semplicemente omettere
l’ID del messaggio: accetta il post, ma non permettere che menta sul fatto di essere un
altro post: dai alla tua copia l’ID generato da Discourse e poi procedi
normalmente.
Grazie ancora per questa risposta meravigliosamente approfondita. Probabilmente mi ci vorrà un po’ per elaborare questo e trasformarlo in azioni concrete, quindi siate pazienti con noi (inoltre, ho altri progetti interni ad alta priorità su cui sto attualmente lavorando). Penso che con queste informazioni saremo in grado di rendere i nostri sistemi di threading molto più robusti e conformi alle specifiche. Potrei avere altre domande man mano che esaminerò il tuo post, grazie Cameron.
Di Martin Brennan tramite Discourse Meta alle 25Lug2022 00:28:
Wow, grazie ancora per questa risposta meravigliosamente approfondita. Probabilmente ci vorrà un po’ di tempo per elaborarla e trasformarla in elementi attuabili, quindi siate pazienti con noi (oltre a questo, ho altri progetti interni ad alta priorità su cui sto attualmente lavorando). Penso che con queste informazioni saremo in grado di rendere i nostri sistemi di threading molto più robusti e conformi alle specifiche. Potrei avere altre domande man mano che esamino il tuo post, grazie Cameron.
Ah, questa è un’osservazione interessante, non avevo notato la piccola freccia.
Anche questo è super interessante. Credo (senza esaminare il codice sorgente) che Thunderbird faccia proprio questo, e probabilmente anche l’interfaccia utente di Gmail, dato che fa la stessa cosa.
Sembra che lo stiamo facendo, ma immagino non in modo coerente? Fondamentalmente dobbiamo assicurarci che:
TODO #1 - Se un post ha un record IncomingEmail associato, usiamo sempre quel Message-ID quando inviamo email.
TODO #2 - Non usare un References quando si inviano email relative all’OP dell’argomento. @cameron-simpson una domanda però: se l’OP è stato creato tramite un’email in entrata, useremmo quel Message-ID in References per l’OP o lo escluderemmo comunque?
Questo è interessante, pensavo che ogni destinatario dell’email dovesse avere un Message-ID univoco? Infatti credo che sia per questo che abbiamo intrapreso la strada di aggiungere unicità al Message-ID di ogni destinatario, per evitare comportamenti di spam, ripensando al nostro argomento interno. Forse @supermathie, che fa parte del nostro team infrastrutturale e ha fatto molti test con le email all’inizio dell’anno, potrebbe intervenire anche qui?
Quello che stai dicendo è che è più il post a determinare un singolo Message-ID per tutti i destinatari. Quindi forse ne generiamo uno per ogni post che genera un’email? Allora potremmo anche spostare qui l’IncomingEmail.message_id. Provvisoriamente, la modifica che dovremmo apportare è:
TODO #3 - Aggiungere un outbound_message_id alla tabella Post. Generarlo una volta quando un’email viene inviata per la prima volta in relazione al post. Usarlo per gli header References e In-Reply-To successivi. Impostare il suo valore quando un post viene creato da un IncomingEmail. Il formato dovrebbe essere topic/:topic_id/:post_id/:stringa_alfanumerica_casuale@host ad esempio topic/233499/33545/gvy8475y7c45y87554c@meta.discourse.org
Dopo questa modifica, il mio primo esempio diventerebbe questo:
Con la considerazione anche che l’OP non ha una gestione speciale, non sarà più nel formato topic/:topic_id@hostname.
TODO #4 - Assicurarsi che vengano generati header In-Reply-To e References corretti basati sui PostReply records e sulla nuova colonna outbound_message_id nella tabella Post
Penso che abbiamo qualche considerazione per questo, controllerò.
Sembra decisamente così
Puoi confermare che i TODO qui sembrano ragionevoli, Cameron? Non sembra molto ora che ci guardo. Mi chiedo anche, quando mi occuperò di questo lavoro, saresti disponibile a unirti a me su un’istanza di Discourse di test su cui verranno distribuite le modifiche WIP, in modo da poterci scambiare email e testare che le cose funzionino correttamente? Ovviamente farò dei test per conto mio prima di coinvolgerti.
Se no, va bene lo stesso – ho Thunderbird e configurerò mutt e potrò testare tutto lì
@cameron-simpson una cosa che volevo chiarire qui è lo scope di “message_id”.
La cosa che ha dato il via a tutto questo è stato il forte sospetto di @supermathie che i nostri message_id non univoci stessero causando problemi.
Discourse genera email univoche per utente per ogni email che invia. Quindi, ad esempio, diciamo che 2 utenti stanno seguendo questo argomento:
L’utente 1 riceve il payload 1 con un link di annullamento dell’iscrizione distinto rivolto all’utente 1
L’utente 2 riceve il payload 2 con un link di annullamento dell’iscrizione distinto rivolto all’utente 2
Se in entrambi i casi il nostro message id fosse, ad esempio, discourse_topic_100/23 (topic_id/post_number), allora diremmo agli MTA che discourse_topic_100/23 può avere 2 payload distinti, l’ipotesi è che li trattino come un segnale di spam.
Ehi Discourse… hai appena inviato due email chiamate discourse_topic_100/23, che succede?
Poiché Discourse controlla tutto il trasporto delle email e le email non vengono aggiunte a una lista BCC o CC come le mailing list tradizionali, possiamo permetterci link di annullamento dell’iscrizione puliti per utente.
Cosa ne pensi? Che ne dici del semplice cambiamento di utilizzare discourse_topic_100/23/7333 ad esempio (topic_id, post_number, user_id) come identificatore univoco per la posta, è certamente un payload univoco e possiamo facilmente farvi riferimento quando generiamo email per un utente.
Di Martin Brennan tramite Discourse Meta il 26 lug 2022 alle 00:27:
Anche questo è estremamente interessante. Credo (senza aver esaminato il codice sorgente) che Thunderbird lo faccia, e probabilmente anche l’interfaccia utente di Gmail, dato che fa la stessa cosa.
Penso che Mutt utilizzi entrambi, ma probabilmente solo In-Reply-To se presente, fallback su References. Dovrei controllare il codice sorgente.
Con References si conosce almeno l’intera catena fino al messaggio originale (OP); con In-Reply-To è più o meno necessario avere i messaggi antecedenti intorno per
assemblare il tutto. Per le mailing list di solito mantengo l’intera
conversazione in locale fino al suo completamento, e mi aspetto che sia una pratica comune.
Sembra che stiamo facendo questo, ma immagino non in modo coerente? Fondamentalmente dobbiamo assicurarci che:
TODO #1 - Se un post ha un record IncomingEmail associato, usiamo sempre quel Message-ID quando inviamo la email.
Sì. È per questo che pensavo che potrebbe essere più sensato avere un campo esplicito
per il message-id, da compilare una sola volta. Poi usarlo da quel momento in poi
sempre, indipendentemente da eventuali cambiamenti nel processo con cui il
message-id viene generato nel codice in seguito.
TODO #2 - Non usare References quando si inviano email relative all’OP del topic.
Sì. L’OP non ha antecedenti, quindi non ci sono References o In-Reply-To.
@cameron-simpson una domanda però – se l’OP è stato creato tramite una
email in arrivo, useremmo quel Message-ID in References per l’
OP o lo escluderemmo comunque?
Escluderlo comunque. Ma usarlo come message-id persistente per l’OP.
Quindi un messaggio scritto via email (OP o risposta) ottiene il suo message-id dalla
email. Uno scritto sul web ne ottiene uno quando l’utente preme
Invia, generato da Discourse. Da quel momento in poi, quello è il message-id, indipendentemente da come è stato creato.
[quote=“Cameron Simpson, post:11, topic:233499,
username:cameron-simpson”]
Puoi semplicemente rimuoveresender_user_id e receiver_user_id dal
campo message-id e ottenere un singolo ID unico che ogni destinatario vede.
Il vincolo di unicità è il post stesso, non il singolo
oggetto “messaggio” a livello di email.
[/quote]
Questo è interessante, pensavo che ogni destinatario della email dovesse avere un Message-ID unico?
No. Il message-id identifica il “messaggio”, non la singola copia. Potrei
pubblicare sul forum e mettere in CC qualcuno direttamente. Se quel qualcuno riceve una
copia direttamente da me e anche tramite il forum, dovrebbero avere lo stesso
message-id.
In effetti credo che questo sia il motivo per cui abbiamo intrapreso la strada di aggiungere
unicità al Message-ID di ogni destinatario, per evitare comportamenti di spam,
guardando indietro al nostro topic interno. Forse @supermathie, che fa parte
del nostro team infrastrutturale e ha fatto un sacco di test con la email all’inizio dell’
anno, potrebbe intervenire anche lui?
Forse. Ma a prima vista, il threading è effettivamente rotto. Sicuramente
inviare lo stesso messaggio a molte persone dovrebbe avere lo stesso message-id,
e in generale, come inoltro (email->discourse->email-destinatari),
discourse non dovrebbe modificare i message-id.
Ciò che stai dicendo è che è più che il post dovrebbe essere ciò che determina un singolo Message-ID per tutti i destinatari. Quindi forse generiamo semplicemente uno per ogni post che genera una email?
Ogni post dovrebbe avere un message-id unico stabile da usare sul lato email.
Se il post è originato da una email, dovrebbe essere usato quel message-id originale.
Altrimenti (tramite l’interfaccia web) Discourse dovrebbe generare un message-id e memorizzarlo con il post.
Potremmo anche spostare IncomingEmail.message_id qui.
Certo. Avere un insieme distinto di campi (il message-id sembra sufficiente)
contenenti lo stato lato email dovrebbe bastare.
Provvisoriamente, la modifica che dovremmo apportare è:
TODO #3 - Aggiungere outbound_message_id alla tabella Post. Generarlo
una volta quando una email viene inviata per la prima volta in relazione al post.
Se hai ricevuto il post da una email, dovresti usare quello, non
generarne uno nuovo.
Usalo per le successive intestazioni References e In-Reply-To. Imposta il suo
valore quando un post viene creato da un IncomingEmail.
Sì. Al message-id della email.
Il formato dovrebbe essere topic/:topic_id/:post_id/:random_alphanumeric_string@host ad esempio topic/233499/33545/gvy8475y7c45y87554c@meta.discourse.org
Per quelli che generate voi stessi, questo mi sembra buono.
Dopo questa modifica il mio primo esempio diventerebbe questo:
Ma nota: il message-id deve solo essere stabile e unico. Se il topic/:topic_id/:post_id@host è stabile e non verrà mai rigenerato,
andrà bene. Ma se sei preoccupato per questo (ad esempio ripristini del database o
migrazioni o importazioni che portano gli stessi numeri) allora la stringa casuale
lo renderà robusto contro collisioni.
Nota che la parte sinistra del message-id è dot-atom-text, definita qui:
che è composta da lettere e cifre e un insieme limitato di caratteri di punteggiatura
(il che include “/”).
Nota le parentesi angolari. Il message-id è formalmente la parte tra le
parentesi angolari, e le parentesi angolari sono obbligatorie. Sintassi qui:
Con la considerazione anche che l’OP non ha una gestione speciale, non sarà più nel formato topic/:topic_id@hostname.
Sembra buono.
TODO #4 - Assicurarsi che vengano generate le intestazioni In-Reply-To e References corrette in base ai record PostReply e alla nuova colonna outbound_message_id nella tabella Post
Grazie.
Penso che abbiamo già una considerazione per questo, controllerò di nuovo.
+1
Sembra decisamente così
Puoi confermare che i TODO qui sembrano ragionevoli, Cameron?
Mi sembrano corretti.
Non sembra granché ora che ci guardo. Mi chiedo anche,
quando arriverò a questo lavoro, saresti disposto a unirti a me su un’istanza di testing
di Discourse che avrà le modifiche WIP distribuite su di essa in modo che possiamo
scambiare email e testare che tutto funzioni correttamente? Naturalmente farò dei test da solo prima di coinvolgerti.
Certamente. Felice di aiutare in qualsiasi modo.
Se no, va bene lo stesso – ho Thunderbird e imposterò mutt e potrò testare tutto lì
Penso che tu possa ancora inviare messaggi distinti con lo stesso message-id, anche con piccole differenze come questa.
Le mailing list ordinarie fanno questo continuamente, in misura maggiore o minore. Almeno una manipolazione dell’intestazione avviene sempre. Ma anche il corpo del messaggio viene talvolta modificato. Un esempio eclatante è python-list, che scarta gli allegati non testuali. Il messaggio passa comunque con lo stesso message-id. E quasi tutte le liste aggiungono una nota in fondo con, ad esempio, un link alla pagina di amministrazione della lista o un link per annullare l’iscrizione. Quella non sarà stata sul messaggio quando è arrivato.
E ci sono state lunghe discussioni sulla firma dei contenuti che ruotano attorno a ciò che dovrebbe essere coperto da una firma.
Quindi sarei assolutamente d’accordo con te nell’aggiungere il tuo link di annullamento iscrizione specifico per il destinatario e nel preservare il message-id originale. I benefici superano di gran lunga la perdita del threading se tu dessi a ciascuna copia del messaggio un message-id individuale.
Ancora una volta, considera l’utente di posta elettronica. Posso rispondere a un messaggio di discourse e aggiungere un CC a una persona esterna interessata. Forse ne riceve una copia da discourse, forse no. Ma se lo facesse, dovrebbe avere il message-id sorgente su di esso anche con il tuo rider aggiuntivo. Altrimenti avrà 2 copie del mio messaggio, ma il suo sistema di posta non saprà che sono copie dello stesso messaggio. Ne consegue il caos.
Quindi, in breve: non penso che il tuo testo aggiuntivo di annullamento iscrizione, molto minore, giustifichi message-id distinti. Mantieni solo quello unico.
Mi dispiace, mi sto aggiornando ora, ecco alcuni pensieri, alcuni dei quali sono già stati affrontati…
La difficoltà qui è che ciò che viene inviato da Discourse è un messaggio diverso da quello in ingresso. Ha metadati diversi (a tal fine, A/Da/Rispondi a/Annulla iscrizione/ecc.) e un corpo diverso (è personalizzato per utente (credo? Questo non accade in modalità mailing list?)).
Cos’è esattamente il messaggio? Trattando il 5322 come vangelo:
Un messaggio è costituito da campi di intestazione, facoltativamente seguiti da un corpo del messaggio.
Il campo “Message-ID:” fornisce un identificatore univoco del messaggio che fa riferimento a una particolare versione di un particolare messaggio.
[enfasi mia]
È proprio “particolare versione” che mi fa pensare che sarebbe inappropriato reinviare un messaggio in arrivo con un Message-ID diverso. Tuttavia, se cambi il tuo punto di vista da Discourse come “Software Forum” a Discourse come “Software Mailing List”, allora ha un certo senso farlo, quindi capisco da dove vieni. 5322 dice anche:
Ci sono molte istanze in cui i messaggi vengono “modificati”, ma tali modifiche non costituiscono una nuova istanza di quel messaggio e, pertanto, il messaggio non riceverebbe un nuovo identificatore di messaggio. Ad esempio, quando i messaggi vengono introdotti nel sistema di trasporto, vengono spesso preceduti da campi di intestazione aggiuntivi come campi di traccia (descritti nella sezione 3.6.7)
e campi rispediti (descritti nella sezione 3.6.6). L’aggiunta di tali campi di intestazione non modifica l’identità del messaggio e, pertanto, viene mantenuto il campo “Message-ID:” originale. In tutti i casi, è il significato che il mittente del messaggio desidera trasmettere (cioè, se si tratta dello stesso
messaggio o di un messaggio diverso) che determina se il campo “Message-ID:” cambia o meno, non alcuna differenza sintattica particolare che
appare (o non appare) nel messaggio.
Suppongo che si riduca a questo: il mittente del messaggio cambia quando Discourse lo invia?
Forse dovremmo usare Resent-Message-ID e simili?
È sempre stato lì, fin dall’822. Ma come dici più tardi, sì, è stato aggiornato.
5322 parla anche direttamente del modo in cui Discourse e Github lo utilizzano:
Il campo “In-Reply-To:” può essere utilizzato per identificare il messaggio (o i messaggi) a cui il nuovo messaggio è una risposta, mentre il campo “References:” può essere utilizzato per identificare un “filo” di conversazione.
Probabilmente in modo leggermente improprio, probabilmente a causa della mancanza di un “Thread Identifier” adatto. Ma questa interpretazione potrebbe non essere ciò che gli autori dell’RFC intendevano… non affronta i messaggi con un “References” ma senza “In-Reply-To”.
La parte difficile di questo è che non stiamo inviando una e-mail, ne stiamo inviando N - una per destinatario - in modo che i loro metadati individuali (Annulla iscrizione, ecc.) possano essere corretti.
E sì, ho visto forti indicazioni durante i test che la determinazione dello spam sarebbe legata a un Message-ID. Se fosse stato visto di nuovo in seguito (stesso utente o utente diverso) sarebbe stato molto più probabile che fosse contrassegnato come spam.
I benefici qui, ad essere onesti, riguardano interamente il threading corretto delle e-mail in alcuni client di posta, a scapito della recapitalità.
L’attuale topic/#{topic_id}/#{post_id}.s#{sender_user_id}r#{receiver_user_id} almeno lo rende coerente per un utente nella sua casella di posta. L’assunzione
La mia più grande preoccupazione è la recapitalità: è già abbastanza difficile far recapitare le e-mail quando non c’è alcuna visibilità da parte dei principali provider.
Ma vedo un forte argomento per far sì che Discourse si comporti più come un software di mailing list in modalità mailing list. @martin Credo che non personalizziamo il corpo del messaggio in modalità mailing list? Pensi che abbia senso adottare un approccio più rigoroso nel preservare e riutilizzare i Message-ID in modalità mailing list?
Non voglio trovarmi in una situazione in cui il perfetto è nemico del sufficientemente buono.
Ora utilizziamo un “suffisso casuale” nei messaggi e questo sta innegabilmente causando problemi.
Abbiamo 3 opzioni sul tavolo:
ID messaggio casuali a cui non è possibile fare riferimento
ID messaggio stabili per argomento/post/utente
ID messaggio stabili per coppia argomento/post
Attualmente siamo nel pianeta (1) che sta causando scompiglio.
Temo che potremmo raggiungere la paralisi decisionale tra (2) e (3).
Forse possiamo semplicemente iniziare con (2) riconoscendo che l’aggiunta di CC extra a un’email da Discourse potrebbe causare comportamenti imprevisti, e almeno fermare la maggior parte dei problemi qui?
ah! Pensavo stessimo già facendo: topic/#{topic_id}/#{post_id}.s#{sender_user_id}r#{receiver_user_id}
Sarei propenso a, nell’interesse di bilanciare le preoccupazioni di unicità ed efficacia della consegna delle email rispetto a quelle della modalità mailing list, fare \(2) per la modalità mailing list disabilitata e (3) per la modalità mailing list abilitata.
Allo stesso modo, con l’intestazione References, sarei propenso a farla assente per il post #1 in un argomento e farla fare riferimento all’argomento (quindi topic/#{topic_id}) e al post a cui si sta rispondendo, se presente.
In realtà ci stavo lavorando stamattina e, sorprendentemente, l’organizzazione in thread in una vista unificata funziona in Thunderbird per la maggior parte dei casi, e penso che l’header 
