No discuss python org estamos discutindo o lado de e-mail do Discourse. A maior reclamação é a falta de encadeamento. Fiz uma pequena investigação nos cabeçalhos e parece que:
o cabeçalho Message-ID é pelo menos único
os cabeçalhos Reply-To e Referencesnão se referem aos Message-IDs de outras mensagens, muito menos ao ID da mensagem à qual são uma resposta
eles se referem a algum ID de mensagem fictício baseado no número do tópico
Isso significa que as pessoas que usam e-mail veem (a) discussões totalmente planas e não encadeadas e (b) a mensagem raiz aparentemente está faltando, porque os cabeçalhos In-Reply-To e References se referem a um ID de mensagem que nunca aparece em nenhuma mensagem.
Isso é ruim e viola a RFC 5322. E torna a experiência de e-mail muito pior do que poderia ser facilmente.
Como exemplo, há um tópico lá cuja primeira mensagem tem estes cabeçalhos:
Novamente, um Message-ID ok, mas In-Reply-To e References completamente sem sentido.
Isso deveria ser fácil de corrigir. A primeira mensagem não deve ter cabeçalhos In-Reply-To nem References. A segunda mensagem deve ter o Message-ID da primeira mensagem nos cabeçalhos In-Reply-To e References.
Por favor, veja a seção 3.6.4 da RFC5322 para detalhes:
Como estão as coisas, os usuários de e-mail veem discussões planas e não estruturadas. Com essas correções, eles podem ter uma exibição encadeada sensata e fácil de seguir.
Estou apenas dando uma olhada na diferença entre HEAD e essa correção.
Parece-me que o atual ainda sempre define References, mesmo que não haja um antecedente - o topic_canonical_reference_id é usado como fallback. Ainda acho que isso está errado, porque não há uma mensagem de e-mail com esse ID.
O In-Reply-To está um pouco mais correto, pois só é definido se post.post_number!=1, mas ainda recorre a topic_canonical_reference_id:
o fallback deveria ser o Message-ID do post #1 se não houver referenced_post_message_ids, e nãotopic_canonical_reference_id
algo no código receipt-of-reply-emails deve estar descartando o cabeçalho In-Reply-To das mensagens de resposta, porque elas deveriam ter preenchido corretamente o array referenced_post_message_ids (“lista”? Sou novo em Ruby)
Cameron, obrigado por abrir este tópico para discussão e fornecer muitos detalhes em suas postagens. Eu sou o responsável por essa “caixa de Pandora”, a partir destes dois commits:
Temos estado cientes de alguns problemas em torno de encadeamento por algum tempo em clientes de e-mail como o Thunderbird, mas isso não representava um grande número de consumidores de encadeamento de e-mail do Discourse, então foi adiado, mas agora que isso está vindo à tona, precisamos dedicar algum tempo para reexaminar o problema e trabalhar em uma solução.
Curiosamente, adicionamos este cabeçalho References ao primeiro e-mail enviado e a todos os subsequentes na época, pois isso faz com que o encadeamento funcione corretamente no Gmail, mas concordo que não é o ideal e provavelmente está causando os problemas de encadeamento, juntamente com o não uso do Message-ID original nos cabeçalhos In-Reply-To e References dos e-mails subsequentes.
Por favor, tenha paciência comigo enquanto examino discussões antigas e o código e trabalho nisso. Enquanto isso, você está ciente de outros clientes de e-mail que estão sendo usados e estão experimentando problemas? Por exemplo, sei que este é um problema no Thunderbird, mas e em relação a outros? Obrigado.
Lamentamos, mas sua mensagem de e-mail para
["incoming+8349bd9eb1f2b582df4f32dbe85c3363@meta.discoursemail.com"]
(com o título Re: [Discourse Meta] [bug] As mensagens de e-mail do Discourse estão
incorretamente encadeadas) não funcionou.
Motivo:
Desculpe, novos usuários só podem colocar 2 links em uma postagem.
Se você puder corrigir o problema, tente novamente.
Vou colocá-la no fórum onde posso capturar e revisar…
Cameron, obrigado por abrir este tópico para discussão e fornecer
muitos detalhes em suas postagens. Sou responsável por essa caixa de Pandora,
a partir destes dois commits:
3b13f1146b2a406238c50d6b45bc9aa721094f46
Isso parece bom. Ele salva este ID com o registro do banco de dados para que as respostas de entrada possam ser vinculadas à mensagem do fórum antecedente?
Além disso, você quer que eu verifique se o sufixo é sintaticamente legal para RFC5322, em termos de caracteres permitidos?
82cb67e67b83c444f068fd6b3006d8396803454f
Este segundo commit parece abordar outro problema que vimos: se uma postagem vem de um e-mail, o message-id de saída enviado aos usuários de e-mail não é o message-id da mensagem de origem do autor. Isso resulta em duas mensagens diferentes do ponto de vista de um cliente de e-mail, e provavelmente quebra as respostas feitas à original em oposição à cópia enviada pelo fórum. Por exemplo:
Para: o fórum
CC: um dos participantes
O participante receberá (bem, poderá receber) uma cópia do fórum e uma cópia direta do autor, e estas serão mensagens distintas em seu lado porque terão message-ids diferentes.
Eu ia fazer um segundo relatório de bug sobre essa questão depois de resolver a questão dos cabeçalhos in-reply-to e references, que é muito mais importante.
Temos estado cientes de alguns problemas em torno do encadeamento há algum tempo em clientes de e-mail como o Thunderbird, mas isso não representou um grande número de consumidores de encadeamento de e-mail do Discourse, então foi adiado, mas agora que isso está vindo à tona, precisamos gastar algum tempo reexaminando o problema e trabalhando em uma correção.
Eu e vários outros usamos mutt. Estou feliz em fazer o que for necessário para ajudar na depuração e revisão de código. Também fui sysadmin de e-mail por muito tempo em vidas passadas.
[quote=“Cameron Simpson, post:1, topic:233499,
username:cameron-simpson”]
É a primeira mensagem. Não deve ter um cabeçalho References, pois não há nenhuma mensagem em lugar nenhum com esse ID.
[/quote]
Interessantemente, adicionamos este cabeçalho References ao primeiro e-mail enviado e a todos os subsequentes na época, pois isso faz com que o encadeamento funcione corretamente no Gmail,
Acho que um cabeçalho References correto (ausente na primeira postagem, como in-reply-to nas respostas) também funcionaria. Mas o GMail tem um relacionamento bastante flexível com os padrões de e-mail às vezes. Tenho um acordo com o gmail; posso fazer alguma depuração lá também. E, em princípio, podemos usar esta própria discussão como campo de teste, talvez.
mas concordo que não é o ideal e provavelmente está causando os problemas de encadeamento
junto com não usar o Message-ID original nos cabeçalhos In-Reply-To e References de e-mail subsequentes.
Por favor, tenha paciência comigo enquanto eu analiso discussões antigas e o código e trabalho nisso.
Sem problemas.
Enquanto isso, você está ciente de outros clientes de e-mail que estão sendo
usados e estão experimentando problemas? Por exemplo, sei que este é um
problema no Thunderbird, mas e em outros? Obrigado.
Definitivamente mutt. Pelo menos com mutt é muito fácil ver os cabeçalhos e também a cadeia de árvore de respostas, que muitas vezes é obscurecida em outros clientes.
O encadeamento de e-mail é inteiramente definido pelos cabeçalhos Message-ID e In-Reply-To. O cabeçalho References começou com USENET para followups, e suportava (lá) múltiplos message-ids; o In-Reply-To suporta apenas um. Parece que References também está presente agora em RFC5322, e vou verificar sua semântica.
Ok, isso é algo bastante grande, por favor, tenha paciência comigo. Primeiro, obrigado por mais uma resposta detalhada e pela oferta de depuração/revisão, é muito útil Na verdade, tenho investigado isso esta manhã e, surpreendentemente, a organização em árvore em uma visualização unificada funciona no Thunderbird para a maioria dos casos, e acho que o cabeçalho References apontando consistentemente para o OP ajuda com isso (por exemplo, o tópico Reference nesta cadeia que está sempre presente é \u003ctopic/53@discoursehosted.martin-brennan.com\u003e.\n\n
\n\nO caso em que a organização em árvore não funciona como pretendido é:\n\n1. Uma postagem é criada no discourse e um e-mail é enviado para aqueles que estão acompanhando o tópico então\n2. Alguém mais responde a essa postagem e um e-mail é enviado para aqueles que estão acompanhando o tópico\n\nNo caso do segundo e-mail, ele recebe um In-Reply-To e References incorretos, pois gera um nesta linha discourse/lib/email/sender.rb at 98bacbd2c6b9fe57167cd32af5eb4839b4a5d1f6 · discourse/discourse · GitHub em vez de usar um existente. Ele deve usar o Message-ID do e-mail que foi enviado primeiro. Na captura de tela, é aqui que as mensagens que seguem este padrão deveriam ser colocadas:\n\n
\n\n\n\n[quote="Cameron Simpson, post:8, topic:233499, username:cameron-simpson"]\nIsso parece bom. Ele salva esse id com o registro do banco de dados para que as respostas de entrada possam ser vinculadas à mensagem do fórum antecedente?\n[/quote]\n\nA resposta é – depende. Se uma postagem for criada no Discourse a partir de um e-mail de entrada, como esta sua, usamos o Message-ID original de entrada dessa postagem quando alguém responde a ela para os cabeçalhos In-Reply-To e References, conforme:\n\ndiscourse/lib/email/sender.rb at 98bacbd2c6b9fe57167cd32af5eb4839b4a5d1f6 · discourse/discourse · GitHub contrário, estamos apenas usando a referência do OP do tópico e gerando uma nova referência, o que obviamente é o que está causando todos os problemas. Em todos os casos, geramos um novo Message-ID toda vez que um e-mail de saída é enviado, o que parece correto e comparável a outros clientes de e-mail.\n\n[quote="Cameron Simpson, post:8, topic:233499, username:cameron-simpson"]\nEste segundo commit parece resolver outro problema que vimos: se uma\npostagem vem de um e-mail, o message-id de saída enviado aos usuários de e-mail não é o message-id da mensagem de origem do autor. Isso resulta\nem duas mensagens diferentes do ponto de vista de um cliente de e-mail e\nprovavelmente quebra as respostas feitas à original em oposição à\ncópia enviada pelo fórum.\n[/quote]\n\nEu acho que entendi o que você quer dizer, acontece assim:\n\n1. cameron envia e-mail para Discourse de mutt que recebe Message-ID: 74398756983476983@mail.com\n2. Discourse cria uma postagem e armazena o Message-ID contra a postagem com um registro IncomingEmail\n3. johndoe está acompanhando o tópico, então eles recebem um e-mail do Discourse com um Message-ID: topic/222/44@discourse.com e nenhuma referência ao Message-ID original 74398756983476983@mail.com\n\nIsso parece correto, que devemos apenas “passar” esse Message-ID para aqueles que estão acompanhando o tópico em vez de gerar o nosso, já que ele já é único? O que então acontece no cliente de e-mail de johndoe se \ncameron também o colocou em cópia nessa mensagem de saída original? Isso parece ser um problema separado, então seria bom abrir outro tópico de bug para ele.\n\n[quote="Cameron Simpson, post:8, topic:233499, username:cameron-simpson"]\nEu e vários outros usamos mutt.\n[/quote]\n\nConfigurarei um cliente mutt localmente para ver o que você também está vendo, nunca testei essa funcionalidade em um cliente baseado em texto (apenas Gmail e Thunderbird), então estou ansioso para ver como fica de qualquer maneira.\n\n-----\n\nMinha linha de pensamento para resolver esses problemas esta manhã foi descartar os sufixos gerados aleatoriamente quando enviamos cabeçalhos Message-ID em e-mails e, em vez disso, mudar para um esquema onde usamos o user_id do usuário remetente e do usuário receptor. O benefício disso é que não há necessidade de armazenar o Message-ID em nenhum lugar (exceto quando um e-mail de entrada cria uma postagem) e, portanto, os cabeçalhos References e In-Reply-To serão sempre consistentes. Deixe-me dar um exemplo. Digamos que tenhamos estes usuários:\n\n* martin - user_id 25\n* cameron - user_id 44\n* sam - user_id 78\n* bob - user_id 999\n\nE então temos este tópico, topic_id 233499, com postagens começando da post_id 100 como o OP. O formato se tornaria topic/#{topic_id}/#{post_id}.s#{sender_user_id}r#{receiver_user_id}. A ordem das operações seria assim:\n\n1. martin cria o OP\n * cameron recebe um e-mail com estes cabeçalhos:\n * Message-ID: topic/233499.s25r44@meta.discourse.org\n * References: topic/233499@meta.discourse.org\n * sam recebe um e-mail com estes cabeçalhos:\n * Message-ID: topic/233499.s25r78@meta.discourse.org\n * References: topic/233499@meta.discourse.org\n\n2. cameron responde via e-mail\n\n * discourse recebe um e-mail com estes cabeçalhos de mutt:\n * Message-ID: 43585349859734@test.com\n * References: topic/233499@meta.discourse.org topic/233499.s25r44@meta.discourse.org\n * In-Reply-To: topic/233499.s25r44@meta.discourse.org\n\n3. discourse (como cameron, do e-mail acima) cria a postagem 101\n\n * sam recebe um e-mail do discourse com estes cabeçalhos:\n * Message-ID: topic/233499/101.s44r78@meta.discourse.org\n * References: 43585349859734@test.com topic/233499@meta.discourse.org\n * In-Reply-To: 43585349859734@test.com\n\n2. sam responde via e-mail para cameron\n\n * discourse recebe um e-mail com estes cabeçalhos do gmail:\n * Message-ID: 5346564746574@gmail.com\n * References: topic/233499/101.s44r78@meta.discourse.org topic/233499@meta.discourse.org\n * In-Reply-To: topic/233499/101.s44r78@meta.discourse.org\n\n4. discourse (como sam, do e-mail acima) cria a postagem 102\n\n * cameron recebe um e-mail do discourse com estes cabeçalhos:\n * Message-ID: topic/233499/102.s78r44@meta.discourse.org\n * References: 5346564746574@gmail.com topic/233499@meta.discourse.org\n * In-Reply-To: 5346564746574@gmail.com\n\n5. bob cria a postagem 103 no tópico, não em resposta a ninguém (note que o References aqui inclui o Message-ID enviado para ambos os usuários para o e-mail do OP)\n * cameron recebe um e-mail com estes cabeçalhos:\n * Message-ID: topic/233499/103.s999r44@meta.discourse.org\n * References: topic/233500@meta.discourse.org topic/23499.s25r44@meta.discourse.org\n * sam recebe um e-mail com estes cabeçalhos:\n * Message-ID: topic/233499/103.s999r78@meta.discourse.org\n * References: topic/233499@meta.discourse.org topic/23499.s25r78@meta.discourse.org\n\n6. cameron responde via e-mail\n\n * discourse recebe um e-mail com estes cabeçalhos de mutt:\n * Message-ID: 6759850728742572@test.com\n * References: topic/233499@meta.discourse.org topic/233499/103.s999r44@meta.discourse.org\n * In-Reply-To: topic/233499/103.s999r44@meta.discourse.org\n\ncaixa de entrada de cameron\n\n* martin - OP do tópico\n * ENVIADO -\u003e para: discourse, RE: OP do tópico\n * sam - resposta à segunda postagem\n * bob - resposta no tópico não para nenhuma postagem específica\n * ENVIADO -\u003e para: discourse, RE: postagem de bob\n\ncaixa de entrada de sam\n\n* martin - OP do tópico\n * cameron - segunda postagem\n * ENVIADO -\u003e para: discourse, RE: segunda postagem\n * bob - resposta no tópico não para nenhuma postagem específica\n\nAcho que isso está correto, você pode dar uma olhada no que escrevi nesses cabeçalhos e verificar se é o que você esperaria desse cenário? A única coisa sobre a qual estou um pouco incerto é se cobri todas as Referências e, claro, testaria isso em um conjunto de e-mails ao vivo em um branch de desenvolvimento antes de implementá-lo. Eu também ainda não testei nada no mutt.\n\n-----\n\nComo nota paralela, também investiguei o que o GitHub faz com seus e-mails de notificação e notei que eles fazem algo semelhante, onde têm uma Reference onipresente (discourse/discourse/pull/252@github.com) que é usada em todos os e-mails relacionados a esse "tópico", que neste caso é uma solicitação de pull do GitHub:\n\n\nReferences: \u003cdiscourse/discourse/pull/252@github.com\u003e \u003cdiscourse/discourse/pull/252/issue_event/7042100517@github.com\u003e\nIn-Reply-To: \u003cdiscourse/discourse/pull/252/issue_event/7042100517@github.com\u003e\n
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.
Uau, obrigado novamente por esta resposta maravilhosamente aprofundada. Provavelmente levará um tempo para eu processar isso e transformá-lo em itens acionáveis, então, por favor, tenha paciência conosco (além disso, tenho outros projetos internos de alta prioridade em que estou trabalhando atualmente). Acho que com essas informações poderemos tornar nossos sistemas de threading muito mais robustos e em conformidade com as especificações. Posso ter mais perguntas à medida que avanço em sua postagem, obrigado Cameron.
Por Martin Brennan via Discourse Meta em 25Jul2022 00:28:
Uau, obrigado novamente por esta resposta incrivelmente aprofundada. Provavelmente levará um tempo para eu processar isso e transformá-lo em itens acionáveis, então seja paciente conosco (além disso, tenho outros projetos internos de alta prioridade nos quais estou trabalhando atualmente). Acho que com essas informações poderemos tornar nossos sistemas de encadeamento muito mais robustos e de acordo com as especificações. Posso ter mais perguntas à medida que avanço em sua postagem, obrigado Cameron.
ou seja, ele preservou o meu message-id original do e-mail. Então o In-Reply-To está correto, e o References pelo menos tem o meu message-id do e-mail nele.
Ah, essa é uma observação interessante, eu não tinha notado a pequena seta.
Isso também é super interessante. Acredito (sem examinar o código) que o Thunderbird faz isso, e provavelmente a interface do Gmail também, já que faz a mesma coisa.
Nós parecemos estar fazendo isso, mas acho que não de forma consistente? Basicamente, precisamos garantir que:
TODO #1 - Se uma postagem tiver um registro IncomingEmail associado, sempre usaremos esse Message-ID ao enviar e-mail.
TODO #2 - Não use References ao enviar e-mails relacionados à OP do tópico.@cameron-simpson uma pergunta, no entanto - se a OP foi criada via um e-mail de entrada, usaríamos esse Message-ID em References para a OP ou ainda o excluiríamos?
Isso é interessante, eu pensei que cada destinatário do e-mail tinha que ter um Message-ID único? Na verdade, acredito que foi por isso que seguimos o caminho de adicionar exclusividade ao Message-ID de cada destinatário, para evitar comportamentos de spam, olhando para trás em nosso tópico interno. Talvez @supermathie, que faz parte de nossa equipe de infraestrutura e fez muitos testes com e-mail no início do ano, também possa opinar aqui?
O que você está dizendo é que é mais que a postagem deve determinar um único Message-ID para todos os destinatários. Então, talvez geremos um para cada postagem que gera um e-mail? Então também poderíamos mover o IncomingEmail.message_id para cá também. Tentativamente, a mudança que precisaríamos fazer é:
TODO #3 - Adicionar um outbound_message_id à tabela Post. Gerá-lo uma vez quando um e-mail é enviado pela primeira vez em relação à postagem. Usá-lo para cabeçalhos References e In-Reply-To subsequentes. Definir seu valor quando uma postagem é criada a partir de um IncomingEmail. O formato deve ser topic/:topic_id/:post_id/:random_alphanumeric_string@host, por exemplo, topic/233499/33545/gvy8475y7c45y87554c@meta.discourse.org
Após essa mudança, meu primeiro exemplo se tornaria isto:
Com a consideração também de que a OP não tem tratamento especial, ela não estará mais no formato topic/:topic_id@hostname.
TODO #4 - Garantir que os cabeçalhos In-Reply-To e References corretos sejam gerados com base nos registros PostReply e na nova coluna outbound_message_id na tabela Post
Eu acho que temos alguma consideração para isso, vou verificar novamente.
Definitivamente parece que sim
Você pode confirmar se os TODOs aqui parecem razoáveis, Cameron? Realmente não parece muito agora que olho para isso. Também me pergunto, quando eu chegar a este trabalho, você estaria aberto a se juntar a uma instância de teste do Discourse comigo que terá as alterações WIP implantadas para que possamos enviar e-mails de um lado para o outro e testar se as coisas estão funcionando corretamente? Eu, é claro, farei testes próprios antes de envolvê-lo.
Se não, tudo bem também - eu tenho o Thunderbird e vou configurar o mutt e posso testar tudo lá
@cameron-simpson uma coisa que eu queria esclarecer aqui é o escopo do “message_id”.
A coisa que deu início a toda essa dança foi uma forte suspeita de @supermathie de que nossos message_ids não únicos estavam causando problemas.
O Discourse gera e-mails únicos por usuário para cada e-mail que envia. Então, por exemplo, digamos que 2 usuários estejam acompanhando este tópico:
Usuário 1 recebe carga útil 1 com um link de cancelamento de inscrição distinto direcionado ao usuário 1
Usuário 2 recebe carga útil 2 com um link de cancelamento de inscrição distinto direcionado ao usuário 2
Se em ambos os casos nosso message id fosse, digamos, discourse_topic_100/23 (topic_id/post_number), então estaríamos dizendo aos MTAs que discourse_topic_100/23 pode ter 2 cargas úteis distintas, a hipótese é que eles tratam isso como um sinal de spam.
Ei Discourse… você acabou de enviar dois e-mails chamados discourse_topic_100/23, o que está acontecendo?
Como o Discourse está no controle de todo o transporte de e-mail e os e-mails não são adicionados a uma lista Cco ou Cc como listas de mala direta tradicionais, podemos nos dar ao luxo de ter links de cancelamento de inscrição limpos por usuário.
Quais são seus pensamentos sobre isso? Que tal a simples mudança de usar discourse_topic_100/23/7333 (por exemplo, topic_id, post_number, user_id) como o identificador exclusivo para o e-mail, é certamente uma carga útil exclusiva e podemos nos referir facilmente a ela ao gerar e-mails para um usuário.
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
Acho que você ainda pode enviar mensagens distintas com o mesmo message-id, mesmo com pequenas diferenças como essa.
Listas de e-mail comuns fazem isso o tempo todo, em maior ou menor grau. No mínimo, alguma manipulação de cabeçalho sempre acontece. Mas o corpo da mensagem também é modificado às vezes. Um exemplo escandaloso é python-list, que descarta anexos que não são de texto. A mensagem continua com o mesmo message-id. E quase todas as listas colocam um aviso na parte inferior com, digamos, um link para a página de administração da lista ou um link de cancelamento de inscrição. Isso não estará na mensagem quando ela chegou.
E houve longas discussões sobre assinatura de conteúdo que giram em torno do que deve ser coberto por uma assinatura.
Portanto, eu estaria totalmente de acordo com você adicionar seu link de cancelamento de inscrição específico do destinatário e preservar o message-id original. Os benefícios superam muitomuito a perda de encadeamento se você desse a cada cópia da mensagem um message-id individual.
Novamente, considere o usuário de e-mail. Posso responder a uma mensagem do Discourse e adicionar um CC a uma pessoa externa interessada. Talvez ela receba uma cópia do Discourse, talvez não. Mas se recebesse, deveria ter o message-id de origem nele, mesmo com seu aviso adicional. Caso contrário, ela terá 2 cópias da minha mensagem, mas o sistema de e-mail dela não saberá que são cópias da mesma mensagem. O caos se instala.
Então, em resumo: não acho que seu texto adicional muito pequeno de cancelamento de inscrição justifique message-ids distintos. Mantenha apenas um.
Desculpe, estou apenas me atualizando agora, aqui estão algumas ideias, algumas das quais já foram abordadas…
A dificuldade aqui é que o que é enviado para fora do Discourse é uma mensagem diferente da recebida. Ela tem metadados diferentes (para este propósito, Para/De/Responder para/Cancelar inscrição/etc.) e um corpo diferente (é personalizado por usuário (acho eu? Isso não acontece no modo lista de e-mails?)).
O que exatamente é a mensagem? Tratando 5322 como regra:
Uma mensagem consiste em campos de cabeçalho, opcionalmente seguidos por um corpo de mensagem.
O campo “Message-ID:” fornece um identificador de mensagem exclusivo que se refere a uma versão específica de uma mensagem específica.
[ênfase minha]
É essa “versão específica” que me faz pensar que seria inapropriado reenviar uma mensagem recebida com um Message-ID diferente. Embora, se você mudar seu ponto de vista de Discourse como “Software de Fórum” para Discourse como “Software de Lista de E-mails”, então de alguma forma faz sentido fazer isso, então entendo seu ponto. 5322 também diz:
Existem muitas instâncias em que as mensagens são “alteradas”, mas essas alterações não constituem uma nova instanciação dessa mensagem e, portanto, a mensagem não receberia um novo identificador de mensagem. Por exemplo, quando as mensagens são introduzidas no sistema de transporte, elas são frequentemente precedidas por campos de cabeçalho adicionais, como campos de rastreamento (descritos na seção 3.6.7) e campos reenviados (descritos na seção 3.6.6). A adição de tais campos de cabeçalho não altera a identidade da mensagem e, portanto, o campo “Message-ID:” original é retido. Em todos os casos, é o significado que o remetente da mensagem deseja transmitir (ou seja, se esta é a mesma mensagem ou uma mensagem diferente) que determina se o campo “Message-ID:” muda ou não, não qualquer diferença sintática particular que apareça (ou não apareça) na mensagem.
Suponho que se resuma a, o remetente da mensagem muda quando o Discourse a envia?
Talvez devêssemos usar Resent-Message-ID e afins?
Sempre esteve lá, desde 822. Mas como você diz mais tarde, sim, foi atualizado.
5322 também fala diretamente sobre como Discourse e Github o usam:
O campo “In-Reply-To:” pode ser usado para identificar a mensagem (ou mensagens) à qual a nova mensagem é uma resposta, enquanto o campo “References:” pode ser usado para identificar um “fio” de conversa.
Possivelmente de forma ligeiramente inadequada, provavelmente devido à falta de um cabeçalho “Thread Identifier” adequado. Mas essa interpretação pode não ser o que os autores do RFC pretendiam… ela não aborda mensagens com “References”, mas sem “In-Reply-To”.
A parte complicada disso é que não estamos enviando um e-mail, estamos enviando N - um por destinatário - para que seus metadados individuais (Cancelar inscrição, etc.) possam estar corretos.
E sim, vi fortes indicações durante os testes de que a determinação de spam estaria ligada a um Message-ID. Se fosse visto novamente mais tarde (mesmo usuário ou usuário diferente), seria muito mais provável ser marcado como spam.
Os benefícios aqui, para ser justo, são inteiramente em torno do encadeamento correto dos e-mails em certos clientes de e-mail, à custa da entregabilidade.
O atual topic/#{topic_id}/#{post_id}.s#{sender_user_id}r#{receiver_user_id} pelo menos o torna consistente para um usuário em sua caixa de correio. A suposição
Minha maior preocupação é a entregabilidade - já é difícil entregar e-mail quando não há visibilidade dos principais provedores.
Mas vejo um forte argumento para fazer o Discourse se comportar mais como software de lista de e-mails no modo lista de e-mails. @martin, acredito que não personalizamos o corpo da mensagem no modo lista de e-mails? Você acha que faz sentido adotar uma abordagem mais rigorosa em torno da preservação e reutilização de Message-IDs no modo lista de e-mails?
Não quero estar em uma situação em que o perfeito seja inimigo do bom o suficiente aqui.
Usamos “sufixo aleatório” agora nas mensagens e isso está inquestionavelmente causando problemas.
Temos 3 opções em jogo:
IDs de mensagem aleatórios que não podem ser referenciados de volta
IDs de mensagem estáveis por tópico/postagem/usuário
IDs de mensagem estáveis por par tópico/postagem
Atualmente estamos no planeta (1) que está causando estragos.
Preocupo-me que possamos chegar à paralisia de decisão entre (2) e (3).
Talvez simplesmente comecemos com (2), reconhecendo que adicionar ccs extras a um e-mail do Discourse pode causar comportamento inesperado, e pelo menos parar a maioria dos problemas aqui?
ah! Pensei que já estávamos fazendo: topic/#{topic_id}/#{post_id}.s#{sender_user_id}r#{receiver_user_id}
Eu estaria inclinado a, no interesse de equilibrar as preocupações de exclusividade e entregabilidade de e-mail versus as do modo lista de e-mail, fazer \(2) para o modo lista de e-mail desativado e (3) para o modo lista de e-mail ativado.
Da mesma forma, com o cabeçalho References, eu estaria inclinado a tê-lo ausente para a postagem nº 1 em um tópico e a referenciá-lo ao tópico (portanto, topic/#{topic_id}) e à postagem à qual está respondendo, se houver.
Na verdade, tenho investigado isso esta manhã e, surpreendentemente, a organização em árvore em uma visualização unificada funciona no Thunderbird para a maioria dos casos, e acho que o cabeçalho 
\n\n[quote="Cameron Simpson, post:8, topic:233499, username:cameron-simpson"]\nIsso parece bom. Ele salva esse id com o registro do banco de dados para que as respostas de entrada possam ser vinculadas à mensagem do fórum antecedente?\n[/quote]\n\nA resposta é – depende. Se uma postagem for criada no Discourse a partir de um e-mail de entrada, como 
I’ve actually been looking into this this morning
