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
Por Martin Brennan via Discourse Meta em 22 de julho de 2022 às 06:34:
Okay, isso é meio que enorme, por favor, tenham paciência comigo. Primeiro, obrigado
pela outra resposta detalhada e pela oferta de depuração/revisão, é
realmente útil Na verdade, tenho investigado isso esta manhã
e, surpreendentemente, a organização por tópicos em uma visão unificada funciona no Thunderbird
para a maioria dos casos, e acho que o cabeçalho References apontando consistentemente
para a mensagem original (OP) ajuda nisso (por exemplo, o tópico Reference
nessa cadeia, que está sempre presente, é <topic/53@discoursehosted.martin-brennan.com>.
Acabei de reler atentamente a seção 3.6.4 do RFC5322. Ela evoluiu em relação
às versões anteriores (822 e 2822) e unificou os cabeçalhos de email In-Reply-To,
os cabeçalhos References do USENET e as citações modernas de
mais de uma mensagem anterior.
O resumo breve:
O Message-ID é um identificador persistente único para uma mensagem.
O In-Reply-To contém todos os message-ids dos quais esta mensagem
é uma resposta direta. Então, se eu responder a um par de mensagens, ele terá
esses 2 message-ids.
O References é uma cadeia de respostas de message-ids antecedentes, da
OP até a mensagem anterior. Então, de fato, ele deve sempre começar com
o message-id da OP.
Então, para discussões como esta, fingindo que rótulos são message-ids:
Também é legal incluir “reply1 reply2” nos references (a
outra cadeia até o reply5), mas o RFC recomenda explicitamente contra isso
porque alguns clientes esperam que os references sejam uma única cadeia linear
de respostas, e não algum digrafo achatado.
Então, minha recomendação para construir os references é usar os
references da mensagem antecedente “primária” com o message-id da
mensagem antecedente primária anexado. Assim, você sempre obtém uma
cadeia linear na ordem correta.
Curiosamente, parece haver alguma organização por tópicos ali.
Mas note: a postagem no topo tem uma pequena seta “é uma resposta”. Mesmo sendo
a postagem 1. Eu suspeito que isso seja devido à entrada “topic” em
References, o que faz o TB pensar que havia uma mensagem anterior (o que,
claro, não havia).
No mundo do mutt, vemos quase nenhuma organização por tópicos:
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
Isso ocorre porque o In-Reply-To de cada mensagem aponta diretamente para o
fictício message-id “topic”. O Mutt provavelmente ignora o References
porque é um leitor de email, e References tem origem nas notícias do USENET.
Talvez o Thunderbird esteja usando os references ou aumentando o in-reply-to
com informações dos references.
Você só precisa consultar um dos In-Reply-To ou References para fazer
a organização por tópicos; o primeiro vem do email e o último do USENET.
Vocês estão dando suporte a ambos (o que é ótimo!), então precisamos torná-los
consistentes.
(Aside: também há discussão sobre espelhamento do USENET, porque várias
pessoas do Python consomem as listas através de uma interface do USENET. Novamente, um
tópico separado.)
[…]
[quote=“Cameron Simpson, post:8, topic:233499,
username:cameron-simpson”]
Isso parece bom. Isso salva esse id com o registro do banco de dados para que respostas
entrantes possam ser vinculadas à mensagem antecedente do fórum?
[/quote]
A resposta é – depende. Se uma postagem é criada no Discourse a partir de um email entrante, como esta sua, usamos o Message-ID original dessa postagem quando alguém responde a ela para os cabeçalhos In-Reply-To e References, conforme:
Caso contrário, estamos apenas usando a referência OP do tópico e apenas gerando uma nova referência, o que obviamente está causando todos os problemas. Em todos os casos, geramos um novo Message-ID sempre que um email de saída é enviado, o que parece correto e à altura de outros clientes de email.
Infelizmente, não exatamente. Se você é a origem da mensagem (ou seja, autorada no
Discourse), gerar o message-id é bom. Se não há message-id
(illegal), gerar um é prática padrão (geralmente por MTAs). Mas se
você está repassando uma mensagem (autorada em email), o message-id existente
deve ser preservado.
Na minha opinião, você precisa fazer 3 coisas:
ter um message-id estável e não substituir o message-id de uma
mensagem entrante
gerar In-Reply-To correto, que é facilmente computado a partir da(s)
mensagem(ões) antecedente(s) imediata(s), ou seja, antecedente(s)-Message-ID
gerar References correto, que é facilmente computado como
antecedente-References + antecedente-Message-ID
Para o ponto 1, olhando o código que você cita, você provavelmente quer que o
message-id do email seja (sintaxe estilo Python, desculpe):
def message_id(post):
return post.incoming_email.message_id or discourse_message_id(post)
ou seja, ser o message-id do email da postagem se ela originou de um email,
caso contrário, o message-id do Discourse usando algo como o algoritmo
que você descreve mais adiante nesta mensagem: qualquer coisa (a) estável e (b)
sintaticamente válida.
Então, computar os campos In-Reply-To e References é coisa mecânica
simples, conforme os pontos 2 e 3.
Acho que entendi o que você quer dizer, é assim mesmo:
cameron envia email para o Discourse a partir do mutt, que recebe Message-ID: 74398756983476983@mail.com
O Discourse cria uma postagem e armazena o Message-ID contra a postagem com um registro IncomingEmail
Correto.
johndoe está assistindo ao tópico, então ele recebe um email do Discourse com um Message-ID: topic/222/44@discourse.com e nenhuma referência ao Message-ID original 74398756983476983@mail.com
Não. Você realmente quer repassar o IncomingEmail.message_id como o Message-ID no email para johndoe. É a mesma mensagem.
Parece correto, que devemos apenas “repassar” esse Message-ID para aqueles que assistem ao tópico em vez de gerar o nosso próprio, já que ele já é único? O que acontece então no cliente de email do johndoe se
cameron também o CCou naquela mensagem de saída original? Isso parece ser um problema separado, então seria bom abrir outro tópico de bug para isso.
Ao repassá-lo, a mensagem original (cameron->cc:johndoe) e a
mensagem encaminhada pelo Discourse (cameron->Discourse->johndoe) têm o mesmo
message-id e o mesmo conteúdo da mensagem. O sistema de email receptor
armazena ambas. O leitor de email vê ambas e ou apresenta ambas ou
mantém apenas uma (isso é uma decisão de política do leitor de email - manter
apenas uma é comum). Como são a mesma mensagem, em geral não
importa qual é mantida.
Se ignorássemos o Discourse e considerássemos uma mensagem que fosse
uma cópia da mensagem via lista e também via email direto. Elas são
a mesma mensagem, com o mesmo message-id.
Vou configurar 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 forma.
Feliz em ajudar com as configurações. Para a visão por tópicos, você precisa definir
a ordenação como threadeed. O Mutt é muito configurável.
Minha linha de pensamento para resolver esses problemas esta manhã foi me livrar
dos sufixos gerados aleatoriamente quando enviamos cabeçalhos Message-ID em emails e, em vez disso, mudar para um esquema onde usamos o user_id tanto do usuário enviador quanto do receptor. A vantagem
disso é que não há necessidade de armazenar o Message-ID em lugar nenhum
( exceto quando um email entrante cria uma postagem) e, portanto, os cabeçalhos References
e In-Reply-To serão sempre consistentes.
Sim, isso é muito melhor. Observando que o message-id do email entrante
deve substituir o message-id derivado do Discourse para o email de saída.
(A maioria dos sistemas de email usa strings aleatórias porque não há contexto
circundante, como a estrutura de mensagens do tópico do Discourse - as mensagens são
consideradas isoladamente; mas o único requisito real é unicidade
persistente.)
Deixe-me dar um exemplo. Digamos que tenhamos estes usuários:
martin - user_id 25
cameron - user_id 44
sam - user_id 78
bob - user_id 999
E então temos este tópico, topic_id 233499, com postagens começando da post_id 100 como a OP. O formato se tornaria topic/#{topic_id}/#{post_id}.s#{sender_user_id}r#{receiver_user_id}.
Não deve haver um cabeçalho References na OP. Ele não é
necessário para a organização por tópicos e efetivamente finge que há alguma “postagem 0”
que não existe. Isso significa que toda OP (a) parece uma resposta, o que não é, e (b) parece que a coisa à qual ela responde está faltando
na caixa de correio do leitor.
Isso cria message-ids diferentes para cada cópia de saída da OP.
Isso é ruim. Eles precisam ser os mesmos. Suponha que sam CC cameron
diretamente em uma resposta. O In-Reply-To citará um message-id que cameron
nunca recebeu.
Você pode apenas remover o sender_user_id e o receiver_user_id do
campo message-id e obter um único id único que todo receptor vê.
A restrição de unicidade é a postagem em si, não o objeto individual
“mensagem” em nível de email.
Sobre o References, a OP não deve ter um. TB e tudo mais
estarão bem. Se eles estão organizando por tópicos usando References em vez de In-Reply-To, os References nas mensagens de resposta são suficientes.
Aqui está o início de um tópico de discussão de lista de correio no 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 que ordeno meu email do mais novo para o topo. Veja que não há seta na
postagem inicial (na parte inferior). Essa mensagem não tem References e
nem In-Reply-To. Todas as outras têm In-Reply-To (e possivelmente References, mas isso é uma lista de correio de email, então não necessariamente; como eu
mencionei antes, eles são complementares.)
Se eu repetir meu exemplo do Discourse de antes:
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
Veja que todas elas têm uma seta inicial? Isso ocorre porque o cliente de email
acredita que todas são respostas a uma mensagem raiz comum (e faltante),
que é devido ao message-id “topic” no cabeçalho References. Enquanto
a postagem 1 é, na verdade, a mensagem inferior exibida acima.
Resumo:
seu plano é bom, desde que você remova o remetente e o receptor do
message-id - eles são desnecessários e, na verdade, o receptor causará
problemas (o remetente é apenas redundante).
remova o pseudo-message-id “topic” dos References - isso engana
clientes de email (incluindo o TB, mesmo que não seja visualmente evidente)
cameron responde via email
discourse recebe um email com estes cabeçalhos do mutt:
Sim, novamente com a ressalva de que não deve haver uma referência “topic”.
Como esperado, há uma referência ao message-id da OP. Embora deva
ser o mesmo message-id que sam vê para a OP.
discourse (como cameron, do email acima) cria a postagem 101
sam recebe um email do discourse com estes cabeçalhos:
E aqui tudo dá errado. O Message-ID deve ser 43585349859734@test.com do campo .incoming_post.message_id.
(Bem, na minha opinião, isso é post.message_id(), que retorna post.incoming_post.message_id para uma postagem gerada por email e a sua
postagem gerada pelo Discourse caso contrário).
Considere: compus e enviei minha resposta com o message-id 43585349859734@test.com. Por motivos de continuidade, mantenho uma cópia disso
na minha pasta local, onde ela aparece como uma resposta à OP. Idealmente,
o Discourse também me envia uma cópia da minha própria postagem (isso é uma configuração de política
em muitas listas de correio), então recebo também a versão do Discourse. Isso deve
ter o mesmo message-id, porque é a mesma mensagem, apenas por um
caminho diferente.
A mensagem do Discourse não está “em resposta” à minha mensagem. Ela é minha
mensagem, apenas encaminhada.
Esse efeito se propaga pelos seus exemplos seguintes. O processo real
deve ser mais simples do que você o tornou.
Pense assim. Se eu respondo a uma postagem por email, isso efetivamente é
como eu enviando um email para sam (e os outros) via Discourse. O Discourse
encaminha minha mensagem para os assinantes que recebem email e,
“acidentalmente”, mantém uma cópia no fórum
Como nota lateral, também investiguei o que o GitHub faz com seus
emails de notificação, e notei que eles fazem algo similar, onde têm um Reference sempre presente
(discourse/discourse/pull/252@github.com) que é usado em todos os
emails relacionados a esse “tópico”, que neste caso é um pull request do GitHub:
Uau, GitHub. Que desastre são os emails de issues deles
No entanto, em seu cenário, o PR é a OP. Então, uma referência direta
ao pull é sensata. Você poderia usar o message-id “topic” para a postagem 1,
desde que não usasse também o id “topic/1”. Mas parece
pouco útil - é esforço extra tratar a postagem 1 como caso especial - eu apenas usaria
“topic/1”.
Para adicionar alguma complicação. Pelo que entendi, um administrador pode mover uma
postagem ou um tópico. Isso não quebra o esquema de “gerar o message-id”,
especialmente se eles moverem apenas uma postagem? Sou da opinião de que
cada postagem deve ter um campo _message_id, preenchido a partir da
mensagem entrante (de email) ou gerado (postagem via Discourse). Então
ele é persistente, estável e robusto contra qualquer embaralhamento de postagens ou
mudanças de algoritmo.
Finalmente, há uma pequena consideração de segurança: você deve ignorar o
message-id do email entrante (e potencialmente rejeitar a mensagem) se ele
afirmar ser o message-id de uma postagem existente. Já que, como autor, posso colocar
o que quiser nesse cabeçalho Eu iria apenas descartar o
message-id - aceitar a postagem, mas não permitir que ela minta sobre ser outra
postagem - dê à sua cópia o id gerado pelo Discourse e depois proceda
normalmente.
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.
Por Martin Brennan via Discourse Meta em 26Jul2022 00:27:
Isso também é super interessante. Acredito (sem examinar o código-fonte) que o Thunderbird faz isso, e provavelmente a interface do Gmail também, já que faz a mesma coisa.
Acho que o mutt usará ambos, mas provavelmente apenas o In-Reply-To se estiver presente, recuando para o References. Eu precisaria verificar o código-fonte.
Com o References, você sabe pelo menos a cadeia completa até o OP; com o In-Reply-To, você mais ou menos precisa das mensagens antecedentes ao redor para juntar as coisas. Para listas de e-mail, eu geralmente mantenho toda a thread localmente até que termine de qualquer forma, e espero que isso seja comum.
Parece que estamos fazendo isso, mas acho que não consistentemente? Basicamente, precisamos garantir que:
TODO #1 - Se um post tiver um registro IncomingEmail associado, usaremos sempre esse Message-ID ao enviar o e-mail.
Sim. É por isso que eu estava pensando que seria mais sensato ter um campo explícito para o message-id e preenchê-lo uma vez. Daí em diante, usá-lo sempre, independentemente de quaisquer alterações no processo em que o message-id é fabricado no código mais tarde.
TODO #2 - Não use um References ao enviar e-mails relacionados ao OP do tópico.
Sim. O OP não tem antecedente, então não há References ou In-Reply-To.
@cameron-simpson uma pergunta, porém — se o OP foi criado via um e-mail de entrada, usaríamos esse Message-ID no References para o OP ou ainda o excluiríamos?
Ainda excluir. Mas use-o como o message-id persistente para o OP.
Então, uma mensagem autorada por e-mail (OP ou resposta) obtém seu message-id do e-mail. Uma autorada na web obtém um quando o usuário pressiona Enviar, gerado pelo Discourse. A partir daí, esse é o message-id, independentemente de como foi criado.
Isso é interessante, eu pensava que cada destinatário do e-mail precisava ter um Message-ID único?
Não. O message-id identifica a “mensagem”. Não a cópia individual. Posso postar no fórum e CC alguém diretamente. Se essa pessoa receber uma cópia diretamente de mim e também via fórum, ela deve ter o mesmo message-id.
Na verdade, acredito que é por isso que seguimos o caminho de adicionar unicidade ao Message-ID de cada destinatário, para evitar comportamentos de spam, olhando para trás em nosso tópico interno. Talvez @supermathie, que está na nossa equipe de infraestrutura e estava fazendo muitos testes com e-mail no início do ano, possa se manifestar aqui também?
Talvez. Mas à primeira vista, a thread está de fato quebrada. Certamente, enviar a mesma mensagem para muitas pessoas deve ter o mesmo message-id, e, em geral, como um encaminhador (e-mail->discourse->destinatários de e-mail), o Discourse não deve modificar os message-ids.
O que você está dizendo é que é mais que o post deve ser a coisa que determina um único Message-ID para todos os destinatários. Então, talvez geremos apenas um para cada post que gera um e-mail?
Todo post deve ter um message-id único e estável para uso no lado do e-mail. Se o post originou-se de um e-mail, esse message-id original deve ser usado. Caso contrário (via interface web), o Discourse deve gerar um message-id e armazená-lo com o post.
Então poderíamos também mover o IncomingEmail.message_id para cá também.
Claro. Ter um conjunto distinto de campos (message-id parece suficiente) contendo o estado do lado do e-mail deve resolver.
Provisoriamente, a mudança que precisaríamos fazer é:
TODO #3 - Adicionar um outbound_message_id à tabela Post. Gerá-lo uma vez quando um e-mail for enviado pela primeira vez em relação ao post.
Se você recebeu o post de um e-mail, deve estar usando esse, não gerando um novo.
Use-o para os cabeçalhos References e In-Reply-To subsequentes. Defina seu valor quando um post for criado a partir de um IncomingEmail.
Sim. Para o message-id do e-mail.
O formato deve ser topic/:topic_id/:post_id/:random_alphanumeric_string@host por exemplo topic/233499/33545/gvy8475y7c45y87554c@meta.discourse.org**
Para os que vocês geram, isso parece bom para mim.
Após essa mudança, meu primeiro exemplo se tornaria este:
Mas note: o message-id só precisa ser estável e único. Se o topic/:topic_id/:post_id@host for estável e nunca for regenerado, isso basta. Mas se você estiver preocupado com isso (por exemplo, restaurações de banco de dados, migrações ou importações trazendo esses mesmos números), então a string aleatória o tornará robusto contra colisões.
Note que a parte esquerda do message-id é dot-atom-text, definida aqui:
que são letras e dígitos e um conjunto limitado de caracteres de pontuação (que inclui “/”).
Note os colchetes angulares. O message-id é formalmente o bit entre os colchetes angulares, e os colchetes angulares são obrigatórios. Sintaxe aqui:
Com a consideração também de que o OP não tem tratamento especial, ele não estará mais no formato topic/:topic_id@hostname.
Parece bom.
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
Obrigado.
Eu acho que temos alguma consideração para isso, vou verificar novamente.
+1
Definitivamente parece assim
Você pode confirmar se os TODOs aqui parecem razoáveis, Cameron?
Parecem corretos para mim.
Realmente não parece muito agora que olho para isso. Também me pergunto, quando eu chegar a esse trabalho, você estaria aberto a entrar em uma instância de teste do Discourse comigo que terá as mudanças WIP implantadas nela para que possamos trocar e-mails e testar se as coisas estão funcionando corretamente? Farei, é claro, meus próprios testes antes de envolvê-lo.
Certamente. Feliz em ajudar de qualquer maneira.
Se não, tudo bem também — eu tenho o Thunderbird e vou configurar o mutt e posso testar tudo lá
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 
