En discuss python org estamos discutiendo el lado del correo electrónico de Discourse. La mayor queja es la falta de encadenamiento. Investigué un poco en las cabeceras y parece que:
la cabecera Message-ID es al menos única
las cabeceras Reply-To y Referencesno se refieren a los Message-IDs de otros mensajes, y mucho menos al ID del mensaje al que están respondiendo
en cambio, se refieren a algún ID de mensaje ficticio basado en el número del tema
Esto significa que las personas que usan el correo electrónico ven (a) discusiones totalmente planas y sin encadenar y (b) el mensaje raíz aparentemente falta, porque las cabeceras In-Reply-To y References se refieren a un ID de mensaje que en realidad nunca aparece en ningún mensaje.
Esto es malo y viola la RFC 5322. Y hace que la experiencia del correo electrónico sea mucho peor de lo que fácilmente podría ser.
Como ejemplo, hay un hilo allí cuyo primer mensaje tiene estas cabeceras:
De nuevo, un Message-ID aceptable, pero In-Reply-To y References completamente sin sentido.
Esto debería ser fácil de arreglar. El primer mensaje no debería tener cabeceras In-Reply-To ni References. El segundo mensaje debería tener el Message-ID del primer mensaje en las cabeceras In-Reply-To y References.
Por favor, consulte la sección 3.6.4 de la RFC 5322 para obtener detalles:
Tal como están las cosas, los usuarios de correo electrónico ven discusiones planas y no estructuradas. Con estas correcciones, pueden tener una visualización encadenada sensata y fácil de seguir.
Solo estoy revisando la diferencia entre HEAD y esa corrección.
Me parece que current todavía siempre establece References, incluso si no hay un antecedente; topic_canonical_reference_id se usa como respaldo. Todavía creo que eso está mal, porque no hay ningún mensaje de correo electrónico con esa ID.
El In-Reply-To es un poco más correcto, en el sentido de que solo se establece si post.post_number!=1, pero todavía recurre a topic_canonical_reference_id:
el respaldo debería ser el Message-ID de la publicación n.º 1 si no hay referenced_post_message_ids, y notopic_canonical_reference_id
algo en el código de receipt-of-reply-emails debe estar eliminando la cabecera In-Reply-To de los mensajes de respuesta, porque deberían haber poblado correctamente el array referenced_post_message_ids (“lista”? Soy nuevo en Ruby)
Cameron, gracias por abrir este tema para discusión y proporcionar muchos detalles en tus publicaciones. Soy responsable de este “cajón de sastre”, de estos dos commits:
Hemos sido conscientes de algunos problemas en torno a la creación de hilos en clientes de correo electrónico como Thunderbird durante un tiempo, pero no representaba un gran número de consumidores de la creación de hilos de correo electrónico desde Discourse, por lo que se ha pospuesto. Pero ahora que esto sale a la luz, necesitamos dedicar tiempo a reexaminar el problema y trabajar en una solución.
Curiosamente, añadimos esta cabecera References al primer correo electrónico enviado y a todos los subsiguientes en su momento, ya que hace que la creación de hilos funcione correctamente en Gmail, pero estoy de acuerdo en que no es ideal y es probable que esté causando los problemas de creación de hilos, junto con no usar el Message-ID original en las cabeceras In-Reply-To y References del correo electrónico subsiguiente.
Por favor, ten paciencia mientras reviso viejas discusiones y el código y trabajo en esto. Mientras tanto, ¿eres consciente de otros clientes de correo electrónico que se estén utilizando y que estén experimentando problemas? Por ejemplo, sé que este es un problema en Thunderbird, pero ¿qué hay de otros? Gracias.
Lo sentimos, pero su mensaje de correo electrónico a
["incoming+8349bd9eb1f2b582df4f32dbe85c3363@meta.discoursemail.com"]
(titulado Re: [Discourse Meta] [bug] Los mensajes de correo electrónico de Discourse se están
enhebrando incorrectamente) no funcionó.
Razón:
Lo sentimos, los nuevos usuarios solo pueden poner 2 enlaces en una publicación.
Si puede corregir el problema, inténtelo de nuevo.
Lo pondré en el foro donde puedo atrapar y revisar…
Cameron, gracias por abrir este tema para discusión y proporcionar
muchos detalles en tus publicaciones. Soy responsable de esta caja de Pandora,
de estos dos commits:
3b13f1146b2a406238c50d6b45bc9aa721094f46
Esto parece estar bien. ¿Guarda este id con el registro de la base de datos para que las respuestas entrantes puedan vincularse al mensaje del foro antecedente?
Además, ¿quieres que verifique que el sufijo sea sintácticamente legal para RFC5322, en términos de caracteres permitidos?
82cb67e67b83c444f068fd6b3006d8396803454f
Este segundo commit parece abordar otro problema que hemos visto: si una publicación proviene de un correo electrónico, el message-id saliente enviado a los usuarios de correo electrónico no es el message-id del mensaje de origen del autor. Esto resulta en dos mensajes diferentes desde el punto de vista de un cliente de correo, y probablemente rompe las respuestas hechas al original en lugar de la copia enviada por el foro. Por ejemplo:
Para: el foro
CC: uno de los participantes
El participante recibirá (bueno, puede) una copia del foro y una copia directa del autor, y estos serán mensajes distintos en su extremo porque tendrán message-ids diferentes.
Iba a hacer un segundo informe de error sobre este problema después de resolver el problema de las cabeceras in-reply-to y references, que es mucho más importante.
Hemos sido conscientes de algunos problemas en torno a la creación de hilos durante un tiempo en clientes de correo electrónico como Thunderbird, pero no ha representado un gran número de consumidores de creación de hilos de correo electrónico de Discourse, por lo que se ha pospuesto, pero ahora que esto sale a la luz, necesitamos dedicar tiempo a reexaminar el problema y trabajar en una solución.
Yo y varios otros usamos mutt. Estoy feliz de hacer lo que sea necesario para ayudar a depurar esto y revisar el código. También he sido administrador de sistemas de correo durante mucho tiempo en vidas anteriores.
[quote=“Cameron Simpson, post:1, topic:233499,
username:cameron-simpson”]
Es el primer mensaje. No debería tener una cabecera References, porque no hay ningún mensaje en ningún lugar con ese id.
[/quote]
Curiosamente, agregamos esta cabecera References al primer correo electrónico enviado y a todos los subsiguientes en ese momento, ya que hace que la creación de hilos funcione correctamente en Gmail,
Creo que una cabecera References correcta (ausente en la primera publicación, como in-reply-to en las respuestas) también debería funcionar. Pero GMail tiene una relación bastante laxa con los estándares de correo en ocasiones. Tengo un acuerdo con gmail; también puedo hacer algo de depuración allí. Y en principio, podemos usar esta misma discusión como campo de pruebas, tal vez.
pero estoy de acuerdo en que no es ideal y probablemente esté causando los problemas de creación de hilos
junto con no usar el Message-ID original en las cabeceras In-Reply-To y References del correo electrónico subsiguiente.
Por favor, tened paciencia conmigo mientras reviso discusiones antiguas y el código y trabajo en esto.
No te preocupes.
Mientras tanto, ¿estás al tanto de otros clientes de correo electrónico que se estén
utilizando y que estén experimentando problemas? Por ejemplo, sé que este es un
problema en Thunderbird, pero ¿en alguno más? Gracias.
Definitivamente mutt. Al menos con mutt es muy fácil ver las cabeceras y también ver la cadena del árbol de respuestas, que a menudo se oculta en otros clientes.
La creación de hilos de correo electrónico se define completamente por las cabeceras Message-ID e In-Reply-To. La cabecera References comenzó con USENET para los seguimientos, y admitía (allí) múltiples message-ids; In-Reply-To admite solo uno. Parece que References también está presente ahora en RFC5322, y revisaré su semántica.
De acuerdo, esto es algo bastante importante, por favor ten paciencia. Primero, gracias por otra respuesta detallada y la oferta de depuración/revisión, es muy útil De hecho, he estado investigando esto esta mañana y, sorprendentemente, la organización en hilo en una vista unificada funciona en Thunderbird para la mayoría de los casos, y creo que la cabecera References que apunta consistentemente al OP ayuda con eso (por ejemplo, el tema Reference en esta cadena que siempre está presente es \u003ctopic/53@discoursehosted.martin-brennan.com\u003e.\n\n
\n\nEl caso en el que la organización en hilo no funciona como se esperaba es:\n\n1. Se crea una publicación dentro de Discourse y se envía un correo electrónico a quienes siguen el tema luego\n2. Alguien más responde a esa publicación y se envía un correo electrónico a quienes siguen el tema\n\nEn el caso del segundo correo electrónico, obtiene una cabecera In-Reply-To y References incorrecta, ya que genera una en esta línea discourse/lib/email/sender.rb at 98bacbd2c6b9fe57167cd32af5eb4839b4a5d1f6 · discourse/discourse · GitHub en lugar de usar una existente. Debería usar el Message-ID del correo electrónico que se envió primero. En la captura de pantalla, aquí es donde deberían colocarse los mensajes que siguen este patrón:\n\n
\n\n\n\n[quote="Cameron Simpson, post:8, topic:233499, username:cameron-simpson"]\nEsto parece correcto. ¿Guarda este id con el registro de la base de datos para que las respuestas entrantes puedan vincularse al mensaje del foro antecedente?\n[/quote]\n\nLa respuesta es: depende. Si se crea una publicación en Discourse a partir de un correo electrónico entrante, como este tuyo, usamos el Message-ID original entrante de esa publicación cuando alguien responde a ella para las cabeceras In-Reply-To y References según:\n\ndiscourse/lib/email/sender.rb at 98bacbd2c6b9fe57167cd32af5eb4839b4a5d1f6 · discourse/discourse · GitHub lo contrario, simplemente usamos la referencia del OP del tema y generamos una nueva referencia, lo que obviamente es lo que está causando todos los problemas. En todos los casos, generamos un nuevo Message-ID cada vez que se envía un correo electrónico saliente, lo que parece correcto y a la par con otros clientes de correo.\n\n[quote="Cameron Simpson, post:8, topic:233499, username:cameron-simpson"]\nEste segundo commit parece abordar otro problema que hemos visto: si una publicación proviene de un correo electrónico, el message-id saliente enviado a los usuarios de correo no es el message-id del mensaje fuente del autor. Esto resulta en dos mensajes diferentes desde el punto de vista de un cliente de correo, y probablemente rompe las respuestas hechas al original en lugar de la copia enviada desde el foro.\n[/quote]\n\nCreo que entiendo lo que quieres decir, ¿sucede así?\n\n1. cameron envía un correo electrónico a Discourse desde mutt que recibe Message-ID: 74398756983476983@mail.com\n2. Discourse crea una publicación y almacena el Message-ID contra la publicación con un registro IncomingEmail\n3. johndoe está siguiendo el tema, por lo que se le envía un correo electrónico desde Discourse con un Message-ID: topic/222/44@discourse.com y sin referencia al Message-ID original 74398756983476983@mail.com\n\n¿Suena correcto, que simplemente “pasemos” ese Message-ID a quienes siguen el tema en lugar de generar el nuestro, ya que ya es único? ¿Qué sucede entonces en el cliente de correo de johndoe si cameron también lo incluyó en copia en ese mensaje saliente original? Esto sí parece un problema separado, por lo que sería bueno abrir otro tema de error para ello.\n\n[quote="Cameron Simpson, post:8, topic:233499, username:cameron-simpson"]\nYo y varios otros usamos mutt.\n[/quote]\n\nConfiguraré un cliente mutt localmente para ver lo que tú también estás viendo, nunca he probado esta funcionalidad en un cliente basado en texto (solo Gmail y Thunderbird), así que tengo curiosidad por ver cómo se ve de todos modos.\n\n-----\n\nMi idea para abordar estos problemas esta mañana fue desechar los sufijos generados aleatoriamente que se generan cuando enviamos cabeceras Message-ID en correos electrónicos y en su lugar cambiar a un esquema donde usamos el user_id tanto del usuario que envía como del que recibe. El beneficio de esto es que no hay necesidad de almacenar el Message-ID en ningún lugar (excepto cuando un correo electrónico entrante crea una publicación) y, por lo tanto, las cabeceras References y In-Reply-To siempre serán consistentes. Permítanme dar un ejemplo. Digamos que tenemos estos usuarios:\n\n* martin - user_id 25\n* cameron - user_id 44\n* sam - user_id 78\n* bob - user_id 999\n\nY luego tenemos este tema, topic_id 233499, con publicaciones a partir de post_id 100 como el OP. El formato se convertiría en topic/#{topic_id}/#{post_id}.s#{sender_user_id}r#{receiver_user_id}. El orden de las operaciones se vería así:\n\n1. martin crea el OP\n * A cameron se le envía un correo electrónico con estas cabeceras:\n * Message-ID: topic/233499.s25r44@meta.discourse.org\n * References: topic/233499@meta.discourse.org\n * A sam se le envía un correo electrónico con estas cabeceras:\n * Message-ID: topic/233499.s25r78@meta.discourse.org\n * References: topic/233499@meta.discourse.org\n\n2. cameron responde por correo electrónico\n\n * A discourse se le envía un correo electrónico con estas cabeceras desde 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, del correo electrónico anterior) crea la publicación 101\n\n * A sam se le envía un correo electrónico desde discourse con estas cabeceras:\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 por correo electrónico a cameron\n\n * A discourse se le envía un correo electrónico con estas cabeceras desde 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, del correo electrónico anterior) crea la publicación 102\n\n * A cameron se le envía un correo electrónico desde discourse con estas cabeceras:\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 crea la publicación 103 en el tema, no en respuesta a nadie (tenga en cuenta que las Referencias aquí incluyen el Message-ID enviado a ambos usuarios para el correo electrónico del OP)\n * A cameron se le envía un correo electrónico con estas cabeceras:\n * Message-ID: topic/233499/103.s999r44@meta.discourse.org\n * References: topic/233500@meta.discourse.org topic/23499.s25r44@meta.discourse.org\n * A sam se le envía un correo electrónico con estas cabeceras:\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 por correo electrónico\n\n * A discourse se le envía un correo electrónico con estas cabeceras desde 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\nbandeja de entrada de cameron\n\n* martin - OP del tema\n * ENVIADO -\u003e a: discourse, RE: OP del tema\n * sam - respuesta a la segunda publicación\n * bob - respuesta en el tema a ninguna publicación en particular\n * ENVIADO -\u003e a: discourse, RE: publicación de bob\n\nbandeja de entrada de sam\n\n* martin - OP del tema\n * cameron - segunda publicación\n * ENVIADO -\u003e a: discourse, RE: segunda publicación\n * bob - respuesta en el tema a ninguna publicación en particular\n\nCreo que esto es correcto, ¿podrías revisar lo que he escrito en estas cabeceras y verificar si es lo que esperarías de este escenario? Lo único de lo que no estoy muy seguro es de si he cubierto todas las Referencias, y por supuesto estaría probando esto en un conjunto de correos electrónicos en vivo en una rama de desarrollo antes de implementarlo. Tampoco he probado nada en mutt todavía.\n\n-----\n\nComo nota aparte, también investigué lo que hace GitHub con sus correos electrónicos de notificación, y noté que hacen algo similar donde tienen una Reference omnipresente (discourse/discourse/pull/252@github.com) que se utiliza en todos los correos electrónicos relacionados con ese “tema”, que en este caso es una solicitud de extracción de 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 a través de Discourse Meta el 22 de julio de 2022 a las 06:34:
Bien, esto es bastante importante, por favor tenedme paciencia. Primero, gracias por otra respuesta detallada y por la oferta de depuración/revisión, es realmente útil De hecho, he estado investigando esto esta mañana y, sorprendentemente, la agrupación en una vista unificada funciona en Thunderbird para la mayoría de los casos, y creo que la cabecera References apuntando consistentemente al OP ayuda en eso (por ejemplo, el Reference del tema en esta cadena, que siempre está presente, es <topic/53@discoursehosted.martin-brennan.com>.
Acabo de releer detenidamente la sección 3.6.4 de la RFC 5322. Ha evolucionado desde versiones anteriores (822 y 2822) y ha fusionado las cabeceras In-Reply-To de correo electrónico, las cabeceras References de USENET y las respuestas modernas que citan más de un mensaje anterior.
El resumen breve:
El Message-ID es un identificador persistente único para un mensaje.
El In-Reply-To contiene todos los message-ids de los que este mensaje es una respuesta directa; así, si respondo a un par de mensajes, contendrá esos 2 message-ids.
El References es una cadena de respuestas de message-ids anteriores, desde el OP hasta el mensaje precedente. Por lo tanto, en efecto, debería siempre comenzar con el message-id del OP.
Así que, para discusiones como esta, fingiendo que las etiquetas son message-ids:
También es legal incluir “reply1 reply2” en los references (la otra cadena hacia reply5), pero la RFC recomienda explícitamente no hacerlo porque algunos clientes esperan que los references sean una única cadena lineal de respuestas, no algún grafo aplanado.
Por lo tanto, mi recomendación para construir los references es utilizar los references del mensaje antecedente “principal” con el message-id del mensaje antecedente principal añadido al final. De esta manera, siempre obtendrás una cadena lineal en el orden correcto.
Curiosamente, parece haber cierta agrupación allí.
Pero notad: la publicación superior tiene una pequeña flecha que indica “es una respuesta”. Aunque es la publicación 1. Supongo que se debe a la entrada “topic” en references, lo que hace que TB piense que hubo un mensaje anterior (lo cual, por supuesto, no hubo).
En el mundo de mutt vemos casi ninguna agrupación:
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
Esto se debe a que el In-Reply-To de cada mensaje apunta directamente al ficticio message-id del "tema. Muttprobablemente ignora losReferencesporque es un lector de correo, yReferencesse originó en las noticias de USENET. Quizás Thunderbird está utilizando losreferenceso complementando elin-reply-tocon información dereferences`.
Solo necesitas consultar uno de In-Reply-To o References para hacer la agrupación; el primero proviene del correo electrónico y el segundo de USENET. Estáis dando soporte a ambos (¡lo cual es genial!), así que necesitamos hacerlos consistentes.
(A parte: también hay discusión sobre la replicación de USENET, porque varias personas de Python consumen las listas a través de una interfaz de USENET. De nuevo, un tema aparte.)
[…]
La respuesta es… depende. Si una publicación se crea en Discourse a partir de un correo electrónico entrante, como este vuestro, utilizamos el Message-ID original de esa publicación entrante cuando alguien responde a ella para las cabeceras In-Reply-To y References, según:
De lo contrario, solo estamos utilizando la referencia del OP del tema y simplemente generando una nueva referencia, lo cual, obviamente, es lo que está causando todos los problemas. En todos los casos, generamos un nuevo Message-ID cada vez que se envía un correo electrónico saliente, lo cual parece correcto y está a la par con otros clientes de correo.
Lamentablemente, no exactamente. Si sois el origen del mensaje (es decir, redactado en Discourse), generar el message-id está bien. Si no hay message-id (ilegal), generar uno es una práctica estándar (generalmente por los MTAs). Pero si estáis reenviando un mensaje (redactado en correo electrónico), el message-id existente debe conservarse.
A mi juicio, tenéis que hacer tres cosas:
Tener un message-id estable y no reemplazar el message-id de un mensaje entrante.
Generar un In-Reply-To correcto, que se calcula fácilmente a partir del(s) mensaje(s) antecedente(s) inmediato(s), es decir, Message-ID del(s) antecedente(s).
Generar References correctos, que se calculan fácilmente como References del antecedente + Message-ID del antecedente.
Para el punto 1, mirando el código que citáis, probablemente queráis que el message-id del correo electrónico sea (sintaxis tipo Python, lo siento):
def message_id(post):
return post.incoming_email.message_id or discourse_message_id(post)
es decir, que sea el message-id del correo electrónico de la publicación si se originó en un correo electrónico, de lo contrario, el message-id de Discourse utilizando algo como el algoritmo que esbozáis más adelante en este mensaje: cualquier cosa (a) estable y (b) sintácticamente válida.
Entonces, calcular los campos In-Reply-To y References es algo mecánico sencillo, como en los puntos 2 y 3.
Creo que entiendo a qué os referís, ¿sucede así:
cameron envía un correo electrónico a Discourse desde mutt que obtiene Message-ID: 74398756983476983@mail.com
Discourse crea una publicación y guarda el Message-ID junto con la publicación mediante un registro IncomingEmail
Correcto.
johndoe está siguiendo el tema, así que recibe un correo electrónico de Discourse con un Message-ID: topic/222/44@discourse.com y ninguna referencia al Message-ID original: 74398756983476983@mail.com`
No. Realmente queréis transmitir IncomingEmail.message_id como el Message-ID en el correo electrónico para johndoe. Es el mismo mensaje.
¿Suena correcto eso, que deberíamos simplemente “retransmitir” ese Message-ID a quienes siguen el tema en lugar de generar el nuestro, ya que ya es único? ¿Qué ocurre entonces en el cliente de correo de johndoe si cameron también lo puso en CC en ese mensaje saliente original? Esto suena como un problema separado, así que sería bueno abrir otro tema de error para ello.
Al retransmitirlo, el mensaje original (cameron->cc:johndoe) y el mensaje reenviado por Discourse (cameron->Discourse->johndoe) tienen el mismo message-id y el mismo contenido del mensaje. El sistema de correo receptor almacena ambos. El lector de correo ve ambos y ya sea presenta ambos o mantiene solo uno (esta es una decisión de política del lector de correo; mantener solo uno es común). Como son el mismo mensaje, en general no importa cuál se mantenga.
Si ignoramos Discourse y consideramos un mensaje que es una copia del mensaje a través de la lista y también a través de correo electrónico directo. Son el mismo mensaje, con el mismo message-id.
Configuraré un cliente mutt localmente para ver lo que también estáis viendo; nunca he probado esta funcionalidad en un cliente basado en texto (solo Gmail y Thunderbird), así que tengo muchas ganas de ver cómo queda de todos modos.
Encantado de ayudar con la configuración. Para la vista agrupada, debéis establecer la clasificación como agrupada. Mutt es muy configurable.
Mi línea de pensamiento para abordar estos problemas esta mañana fue deshacerme de los sufijos generados aleatoriamente que generamos cuando enviamos cabeceras Message-ID en correos electrónicos y, en su lugar, cambiar a un esquema donde utilicemos el user_id tanto del usuario que envía como del que recibe. La ventaja de esto es que no hay necesidad de almacenar el Message-ID en ningún lugar (excepto cuando un correo electrónico entrante crea una publicación) y, por lo tanto, las cabeceras References e In-Reply-To siempre serán consistentes.
Sí, eso es mucho mejor. Teniendo en cuenta que el message-id del correo electrónico entrante debe anular el message-id derivado de Discourse para el correo electrónico saliente.
(La mayoría de los sistemas de correo utilizan cadenas aleatorias porque no hay contexto circundante, como la estructura de mensajes del tema de Discourse; los mensajes se consideran por separado; pero el único requisito real es la unicidad persistente.)
Déjame dar un ejemplo. Digamos que tenemos estos usuarios:
martin - user_id 25
cameron - user_id 44
sam - user_id 78
bob - user_id 999
Y luego tenemos este tema, topic_id 233499, con publicaciones que comienzan desde post_id 100 como el OP. El formato sería topic/#{topic_id}/#{post_id}.s#{sender_user_id}r#{receiver_user_id}.
El orden de operaciones sería así:
martin crea el OP
cameron recibe un correo electrónico con estas cabeceras:
No debería haber ninguna cabecera References en el OP. No es necesaria para la agrupación y efectivamente finge que existe algún “post 0” que no existe. Significa que cada OP (a) parece una respuesta, lo cual no lo es, y (b) parece que el mensaje al que responde falta en el buzón del lector.
Esto genera diferentes message-ids para cada copia saliente del OP. Eso es malo. Deben ser iguales. Supongamos que sam pone en CC directamente a cameron en una respuesta. El In-Reply-To citará un message-id que cameron nunca ha recibido.
Simplemente podéis omitir el sender_user_id y el receiver_user_id del campo message-id y obtener un único ID que todo receptor ve.
La restricción de unicidad es la publicación en sí, no el objeto individual de “mensaje” a nivel de correo electrónico.
En cuanto a los References, el OP no debería tener ninguno. TB y todo lo demás estarán bien. Si están agrupando utilizando References en lugar de In-Reply-To, los References en los mensajes de respuesta son suficientes.
Aquí está el inicio de un hilo de discusión de lista de correo en 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
Ignorad que ordeno mi correo electrónico del más reciente al más antiguo. Ved que no hay flecha en la publicación inicial (en la parte inferior). Ese mensaje no tiene References ni In-Reply-To. Todos los demás tienen In-Reply-To (y posiblemente References, pero esto es una lista de correo de correo electrónico, así que no necesariamente; como mencioné antes, son complementarios).
Si repito mi ejemplo de 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
Ved que todos tienen una flecha inicial? Eso se debe a que el cliente de correo cree que todos son respuestas a un mensaje raíz común (y faltante), lo cual se debe al message-id del “tema” en la cabecera References. Mientras que la publicación 1 es en realidad el mensaje inferior mostrado arriba.
Resumen:
vuestro plan es bueno, siempre que omitáis el remitente y el destinatario del message-id; son innecesarios y, de hecho, el destinatario causará problemas (el remitente es simplemente redundante).
eliminad el pseudo-message-id del “tema” de los References; engaña a los clientes de correo (incluido TB, incluso si no es evidente visualmente).
cameron responde por correo electrónico
discourse recibe un correo electrónico con estas cabeceras desde mutt:
Sí, de nuevo con la salvedad de que no debería haber una referencia al “tema”. Como era de esperar, hay una referencia al message-id del OP. Aunque debería ser el mismo message-id que sam ve para el OP.
discourse (como cameron, desde el correo electrónico anterior) crea la publicación 101
sam recibe un correo electrónico de discourse con estas cabeceras:
Y aquí es donde se va mal. El Message-ID debería ser 43585349859734@test.com del campo .incoming_post.message_id. (Bueno, en mi mente esto es post.message_id(), que devuelve post.incoming_post.message_id para una publicación generada por correo electrónico y la vuestra generada por Discourse en caso contrario).
Considerad: redacto y envío mi respuesta con message-id43585349859734@test.com. Por razones de continuidad, guardo una copia en mi carpeta local, donde aparece como una respuesta al OP. Idealmente, Discourse también me envía una copia de mi propia publicación (esto es una configuración de política en muchas listas de correo), así que también recibo la versión de Discourse. Eso debería tener el mismomessage-id, porque es el mismo mensaje, solo por una ruta diferente.
El mensaje de Discourse no está “en respuesta a” mi mensaje. Es mi mensaje, solo reenviado.
Este efecto se propaga a través de vuestros siguientes ejemplos. El proceso real debería ser más simple de lo que lo habéis hecho.
Pensad en ello así. Si respondo a una publicación desde el correo electrónico, es efectivamente como si yo enviara un correo electrónico a sam (y a los demás) a través de Discourse. Discourse reenvía mi mensaje a los suscriptores que reciben correo electrónico y, “por casualidad”, guarda una copia en el foro
Como nota al margen, también investigué lo que hace GitHub con sus correos electrónicos de notificación, y noté que hacen algo similar donde tienen un Reference siempre presente (discourse/discourse/pull/252@github.com) que se utiliza en todos los correos electrónicos relacionados con ese “tema”, que en este caso es una solicitud de extracción de GitHub:
Vaya, GitHub. ¡Qué desastre son sus correos electrónicos de problemas!
Sin embargo, en su escenario, la PR es el OP. Así que una referencia directa a la extracción es sensata. Podríais utilizar el message-id del “tema” para la publicación 1, siempre que no utilizarais también el ID “tema/1”. Pero parece poco útil; es un esfuerzo extra hacer un caso especial para la publicación 1; yo simplemente usaría “tema/1”.
Para añadir algo de complicación. Según entiendo, un administrador puede mover una publicación o un tema. ¿Eso no rompe el esquema de “generar el message-id”, especialmente si mueven solo una publicación? Soy de la opinión de que cada publicación debería tener un campo _message_id, rellenado desde el mensaje entrante (desde correo electrónico) o generado (publicación a través de Discourse). Entonces es persistente, estable y robusto ante cualquier reordenación de publicaciones o cambios de algoritmo.
Finalmente, hay una pequeña consideración de seguridad: debéis ignorar el message-id del correo electrónico entrante (y potencialmente rechazar el mensaje) si afirma ser el message-id de una publicación existente. Como autor, puedo poner lo que quiera en esa cabecera Yo optaría simplemente por omitir el message-id; aceptar la publicación, pero no permitir que mienta sobre ser otra publicación; darle a vuestro copia el ID generado por Discourse y luego proceder con normalidad.
Wow, gracias de nuevo por esta respuesta maravillosamente detallada. Probablemente me tomará un tiempo procesarla y convertirla en elementos procesables, así que ten paciencia con nosotros (además de esto, tengo otros proyectos internos de alta prioridad en los que estoy trabajando actualmente). Creo que con esta información podremos hacer que nuestros sistemas de subprocesos sean mucho más robustos y cumplan con las especificaciones. Puede que tenga más preguntas a medida que revise tu publicación, gracias Cameron.
Por Martin Brennan vía Discourse Meta el 25Jul2022 00:28:
Muchas gracias de nuevo por esta respuesta maravillosamente detallada. Probablemente me tome un tiempo procesarla y convertirla en elementos prácticos, así que tengan paciencia con nosotros (además de esto, tengo otros proyectos internos de alta prioridad en los que estoy trabajando actualmente). Creo que con esta información podremos hacer que nuestros sistemas de hilos sean mucho más robustos y cumplan las especificaciones. Puede que tenga más preguntas a medida que revise su publicación, gracias Cameron.
es decir, ha conservado mi message-id de correo electrónico original. Por lo tanto, In-Reply-To es correcto, y References al menos tiene mi message-id de correo electrónico.
Ah, esa es una observación interesante, no había notado la pequeña flecha.
Esto también es súper interesante. Creo (sin examinar el código) que Thunderbird hace eso, y probablemente la interfaz de Gmail también, ya que hace lo mismo.
Parece que estamos haciendo esto, pero supongo que no de manera consistente. Básicamente, necesitamos asegurarnos de que:
TODO #1 - Si una publicación tiene un registro IncomingEmail asociado, siempre usamos ese Message-ID al enviar correos electrónicos.
TODO #2 - No usar References al enviar correos electrónicos relacionados con el OP del tema.@cameron-simpson, una pregunta: si el OP se creó a través de un correo electrónico entrante, ¿usaríamos ese Message-ID en References para el OP o aún lo excluiríamos?
Esto es interesante, ¿pensé que cada destinatario del correo electrónico tenía que tener un Message-ID único? De hecho, creo que por eso seguimos el camino de agregar unicidad al Message-ID de cada destinatario, para evitar comportamientos de spam, mirando hacia atrás en nuestro tema interno. Quizás @supermathie, que está en nuestro equipo de infraestructura y estuvo haciendo muchas pruebas con el correo electrónico a principios de año, podría opinar aquí también.
Lo que dices es que es más bien la publicación la que debe determinar un único Message-ID para todos los destinatarios. Entonces, ¿quizás generamos uno para cada publicación que genera un correo electrónico? Luego también podríamos mover el IncomingEmail.message_id aquí también. Tentativamente, el cambio que necesitaríamos hacer es:
TODO #3 - Agregar un outbound_message_id a la tabla Post. Generarlo una vez cuando se envía un correo electrónico por primera vez en relación con la publicación. Usarlo para las cabeceras References e In-Reply-To posteriores. Establecer su valor cuando una publicación se crea a partir de un IncomingEmail. El formato debe ser topic/:topic_id/:post_id/:random_alphanumeric_string@host por ejemplo, topic/233499/33545/gvy8475y7c45y87554c@meta.discourse.org
Después de este cambio, mi primer ejemplo se convertiría en esto:
martin crea el OP
cameron recibe un correo electrónico con estas cabeceras:
Con la consideración también de que el OP no tiene un manejo especial, ya no tendrá el formato topic/:topic_id@hostname.
TODO #4 - Asegurar que se generen las cabeceras In-Reply-To y References correctas basadas en los registros PostReply y la nueva columna outbound_message_id en la tabla Post
Creo que tenemos alguna consideración para esto, lo comprobaré.
Definitivamente parece que sí :sonrisa_sudorosa:
¿Puedes confirmar que los TODOs aquí suenan razonables, Cameron? Realmente no parece mucho ahora que lo miro. También me pregunto, cuando llegue a este trabajo, ¿estarías abierto a unirte a una instancia de Discourse de prueba conmigo que tenga los cambios de WIP desplegados para que podamos enviarnos correos electrónicos de ida y vuelta y probar que las cosas funcionan correctamente? Por supuesto, haré pruebas por mi cuenta antes de involucrarte.
Si no, está bien también, tengo Thunderbird y configuraré mutt y podré probarlo todo allí
@cameron-simpson una cosa que quería aclarar aquí es el ámbito de “message_id”.
Lo que inició todo este baile fue una fuerte sospecha de @supermathie de que nuestros message_ids no únicos estaban causando problemas.
Discourse genera correos electrónicos únicos por usuario para cada correo electrónico que envía. Así, por ejemplo, digamos que 2 usuarios están siguiendo este tema:
El Usuario 1 recibe la carga útil 1 con un enlace de cancelación de suscripción distinto dirigido al usuario 1
El Usuario 2 recibe la carga útil 2 con un enlace de cancelación de suscripción distinto dirigido al usuario 2
Si en ambos casos nuestro message id fuera, por ejemplo, discourse_topic_100/23 (topic_id/post_number), entonces estaríamos diciendo a los MTA que discourse_topic_100/23 puede tener 2 cargas útiles distintas. La hipótesis es que lo tratan como una señal de spam.
Oye Discourse… acabas de enviar dos correos electrónicos llamados discourse_topic_100/23, ¿qué pasa?
Dado que Discourse controla todo el transporte de correo electrónico y los correos electrónicos no se añaden a una lista CCO o CC como las listas de correo tradicionales, podemos permitirnos tener enlaces de cancelación de suscripción limpios por usuario.
¿Qué opinas? ¿Qué hay del simple cambio de usar discourse_topic_100/23/7333 (es decir, topic_id, post_number, user_id) como identificador único para el correo? Ciertamente es una carga útil única y podemos referirnos fácilmente a ella al generar correos para un usuario.
Por Martin Brennan a través de Discourse Meta el 26 de julio de 2022 a las 00:27:
Esto también es muy interesante. Creo (sin examinar el código fuente) que Thunderbird hace eso, y probablemente la interfaz de Gmail también, ya que hace lo mismo.
Creo que mutt utilizará ambos, pero probablemente solo In-Reply-To si está presente, revertiendo a References. Tendría que verificar el código fuente.
Con References al menos conoces toda la cadena hasta el OP; con In-Reply-To más o menos necesitas los mensajes antecedentes alrededor para unir las cosas. Para listas de correo, por lo general mantengo todo el hilo localmente hasta que termina de todos modos, y espero que eso sea común.
Parece que estamos haciendo esto, pero supongo que no de manera consistente? Básicamente necesitamos asegurarnos de que:
TODO #1 - Si una publicación tiene un registro IncomingEmail asociado, siempre usaremos ese Message-ID al enviar el correo electrónico.
Sí. Por eso pensé que podría ser lo más sensato tener un campo explícito para el message-id y llenarlo una vez. Luego usarlo a partir de entonces siempre, independientemente de cualquier cambio en el proceso mediante el cual se genera el message-id en el código más adelante.
TODO #2 - No usar References al enviar correos electrónicos relacionados con el OP del tema.
Sí. El OP no tiene antecedentes, por lo que no hay References ni In-Reply-To.
@cameron-simpson una pregunta, sin embargo: si el OP fue creado a través de un correo electrónico entrante, ¿usaríamos ese Message-ID en References para el OP o aún lo excluiríamos?
Todavía excluirlo. Pero úsalo como el message-id persistente para el OP.
Así que un mensaje redactado por correo electrónico (OP o respuesta) obtiene su message-id del correo electrónico. Uno redactado en la web obtiene uno cuando el usuario presiona Enviar, generado por Discourse. A partir de entonces, ese es el message-id, sin importar cómo se haya creado.
Esto es interesante, pensé que cada destinatario del correo electrónico tenía que tener un Message-ID único.
No. El message-id identifica el «mensaje». No la copia individual. Podría publicar en el foro y CC a alguien directamente. Si esa persona recibe una copia directamente de mí y también a través del foro, debería tener el mismo message-id.
De hecho, creo que por eso seguimos el camino de añadir unicidad al Message-ID de cada destinatario, para evitar comportamientos de spam, mirando hacia atrás en nuestro tema interno. Quizás @supermathie, quien está en nuestro equipo de infraestructura y estaba haciendo muchas pruebas con correo electrónico a principios de año, pueda opinar aquí también.
Quizás. Pero a primera vista, los hilos están realmente rotos. Ciertamente, enviar el mismo mensaje a muchas personas debería tener el mismo message-id, y en general, como reenviador (correo electrónico → Discourse → destinatarios de correo electrónico), Discourse no debería modificar los message-ids.
Lo que estás diciendo es que más bien la publicación debería ser lo que determine un único Message-ID para todos los destinatarios. Así que quizás simplemente generemos uno para cada publicación que genere un correo electrónico.
Cada publicación debería tener un message-id único y estable para su uso en el lado del correo electrónico. Si la publicación se originó en un correo electrónico, se debe usar ese message-id original. De lo contrario (a través de la interfaz web), Discourse debería generar un message-id y almacenarlo con la publicación.
Entonces también podríamos mover IncomingEmail.message_id aquí también.
Claro. Tener un conjunto distinto de campos (message-id parece suficiente) que contengan el estado del lado del correo electrónico debería bastar.
Tentativamente, el cambio que necesitaríamos hacer es:
TODO #3 - Añadir un outbound_message_id a la tabla Post. Generarlo una vez cuando se envíe un correo electrónico por primera vez en relación con la publicación.
Si obtuviste la publicación de un correo electrónico, deberías estar usando ese, no generar uno nuevo.
Úsalo para los encabezados References y In-Reply-To subsiguientes. Establece su valor cuando se crea una publicación a partir de un IncomingEmail.
Sí. Al message-id del correo electrónico.
El formato debe ser topic/:topic_id/:post_id/:random_alphanumeric_string@host por ejemplo topic/233499/33545/gvy8475y7c45y87554c@meta.discourse.org
Para los que generéis vosotros mismos, esto me parece bien.
Después de este cambio, mi primer ejemplo sería esto:
martin crea el OP
cameron recibe un correo electrónico con estos encabezados:
Pero nota: el message-id solo necesita ser estable y único. Si topic/:topic_id/:post_id@host es estable y nunca se volverá a generar, eso bastará. Pero si te preocupa eso (por ejemplo, restauraciones de base de datos, migraciones o importaciones que traigan esos mismos números), entonces la cadena aleatoria lo hará robusto contra colisiones.
Nota que la parte izquierda del message-id es dot-atom-text, definida aquí:
que son letras, dígitos y un conjunto limitado de caracteres de puntuación (que incluye «/»).
Nota los corchetes angulares. El message-id es formalmente el contenido entre los corchetes angulares, y los corchetes son obligatorios. Sintaxis aquí:
Con la consideración también de que el OP no tiene un manejo especial, ya no estará en el formato topic/:topic_id@hostname.
Suena bien.
TODO #4 - Asegurar que se generen los encabezados In-Reply-To y References correctos basados en los registros PostReply y la nueva columna outbound_message_id en la tabla Post
Gracias.
Creo que tenemos alguna consideración para esto, lo verificaré de nuevo.
+1
Definitivamente parece así
¿Puedes confirmar que los TODOs aquí suenan razonables, Cameron?
Me parecen correctos.
Realmente no parece mucho ahora que lo miro. También me pregunto, cuando llegue a este trabajo, ¿estarías abierto a unirte a una instancia de Discourse de prueba conmigo que tendrá los cambios WIP desplegados en ella para que podamos enviarnos correos electrónicos y probar que todo funciona correctamente? Por supuesto, haré mis propias pruebas antes de involucrarte.
Claro. Feliz de ayudar de la manera que sea.
Si no, también está bien; tengo Thunderbird y configuraré mutt y puedo probarlo todo allí
Aún creo que puedes enviar mensajes distintos con el mismo message-id, incluso con pequeñas diferencias como esta.
Las listas de correo ordinarias hacen esto todo el tiempo en mayor o menor medida. Al menos siempre ocurre alguna manipulación de las cabeceras. Pero el cuerpo del mensaje también se modifica a veces. Un ejemplo egregio es python-list, que descarta los adjuntos que no son de texto. El mensaje continúa con el mismo message-id. Y casi todas las listas añaden un aviso al final con, por ejemplo, un enlace a la página de administración de la lista o un enlace para darse de baja. Eso no habrá estado en el mensaje cuando llegó.
Y ha habido largas discusiones sobre la firma de contenido que giran en torno a lo que debe cubrir una firma.
Así que estaría totalmente de acuerdo con que añadas tu enlace de cancelación de suscripción específico para el destinatario y conserves el message-id original. Los beneficios superan con creces la pérdida de encadenamiento si dieras a cada copia del mensaje un message-id individual.
De nuevo, considera al usuario de correo electrónico. Puedo responder a un mensaje de Discourse y añadir una copia a una persona externa interesada. Quizás reciba una copia de Discourse, o quizás no. Pero si lo hiciera, debería tener el message-id de origen, incluso con tu aviso adicional. De lo contrario, tendrá 2 copias de mi mensaje, pero su sistema de correo no sabrá que son copias del mismo mensaje. Se producirán problemas.
Así que, en resumen: No creo que tu texto adicional de cancelación de suscripción, muy menor, justifique message-id distintos. Conserva solo uno.
Lo siento, me estoy poniendo al día ahora, aquí hay algunas ideas, algunas de las cuales ya han sido abordadas…
La dificultad aquí es que lo que se envía desde Discourse es un mensaje diferente al entrante. Tiene metadatos diferentes (para este propósito, Para/De/Responder a/Cancelar suscripción/etc.) y un cuerpo diferente (está personalizado por usuario (¿creo? ¿No sucede esto en el modo de lista de correo?)).
¿Qué es exactamente el mensaje? Tratando 5322 como dogma:
Un mensaje consta de campos de encabezado, opcionalmente seguidos por un cuerpo de mensaje.
El campo “Message-ID:” proporciona un identificador de mensaje único que se refiere a una versión particular de un mensaje particular.
[énfasis mío]
Es esa “versión particular” la que me hace pensar que sería inapropiado reenviar un mensaje entrante con un Message-ID diferente. Sin embargo, si cambias tu punto de vista de Discourse como “Software de Foro” a Discourse como “Software de Lista de Correo”, entonces de alguna manera tiene sentido hacerlo, así que entiendo de dónde vienes. 5322 también dice:
Hay muchas instancias en las que los mensajes se “cambian”, pero esos cambios no
constituyen una nueva instancia de ese mensaje, y por lo tanto el mensaje
no obtendría un nuevo identificador de mensaje. Por ejemplo, cuando los mensajes se
introducen en el sistema de transporte, a menudo se anteponen
campos de encabezado adicionales como campos de rastreo (descritos en la sección 3.6.7)
y campos reenviados (descritos en la sección 3.6.6). La adición de tales encabezados
los campos no cambia la identidad del mensaje y, por lo tanto, el original
se conserva el campo “Message-ID:”. En todos los casos, es el significado que el
remitente del mensaje desea transmitir (es decir, si este es el mismo
mensaje o un mensaje diferente) lo que determina si el
campo “Message-ID:” cambia, no cualquier diferencia sintáctica particular que
aparece (o no aparece) en el mensaje.
Supongo que se reduce a si el remitente del mensaje cambia cuando Discourse lo envía.
¿Quizás deberíamos usar Resent-Message-ID y sus amigos?
Siempre ha estado ahí, desde 822. Pero como dices más tarde, sí, se ha actualizado.
5322 también habla directamente de la forma en que Discourse y Github lo usan:
El campo “In-Reply-To:” puede usarse para identificar el mensaje (o mensajes) al
que el nuevo mensaje es una respuesta, mientras que el campo “References:” puede usarse para
identificar un “hilo” de conversación.
Posiblemente de forma ligeramente incorrecta, probablemente debido a la falta de un “Identificador de Hilo” adecuado. Pero esta interpretación puede no ser lo que los autores del RFC pretendían… no aborda mensajes con “References” pero sin “In-Reply-To”.
Lo complicado de esto es que no estamos enviando un correo electrónico, estamos enviando N, uno por destinatario, para que sus metadatos individuales (Cancelar suscripción, etc.) sean correctos.
Y sí, vi fuertes indicios durante las pruebas de que la determinación de spam estaría ligada a un Message-ID. Si se volviera a ver más tarde (mismo usuario o diferente usuario) sería mucho más probable que se marcara como spam.
Los beneficios aquí, para ser justos, son enteramente para encadenar correctamente los correos electrónicos en ciertos clientes de correo, a expensas de la entregabilidad.
El topic/#{topic_id}/#{post_id}.s#{sender_user_id}r#{receiver_user_id} actual al menos lo hace consistente para un usuario en su buzón. La suposición
Mi mayor preocupación es la entregabilidad: ya es bastante difícil que el correo electrónico se entregue cuando no hay visibilidad de los principales proveedores.
Pero veo un fuerte argumento para hacer que Discourse se comporte más como software de lista de correo en modo de lista de correo. @martin, creo que no personalizamos el cuerpo del mensaje en modo de lista de correo, ¿verdad? ¿Crees que tiene sentido adoptar un enfoque más estricto para conservar y reutilizar Message-IDs en modo de lista de correo?
No quiero estar en una situación en la que lo perfecto sea enemigo de lo suficientemente bueno aquí.
Ahora usamos “sufijo aleatorio” en los mensajes y esto está causando indudablemente problemas.
Tenemos 3 opciones sobre la mesa:
IDs de mensaje aleatorios que no se pueden referenciar.
IDs de mensaje estables por tema/publicación/usuario.
IDs de mensaje estables por par tema/publicación.
Actualmente estamos en el planeta (1) que está causando estragos.
Me preocupa que podamos llegar a una parálisis de decisiones entre (2) y (3).
¿Quizás simplemente comenzamos con (2) reconociendo que agregar CC adicionales a un correo electrónico de Discourse puede causar un comportamiento inesperado, y al menos detener la mayor parte del problema aquí?
¡Ah! Pensé que ya estábamos haciendo: topic/#{topic_id}/#{post_id}.s#{sender_user_id}r#{receiver_user_id}
Me inclinaría a, en aras de equilibrar las preocupaciones de unicidad y entregabilidad del correo electrónico frente a las del modo lista de correo, hacer \(2) para el modo lista de correo deshabilitado y (3) para el modo lista de correo habilitado.
De manera similar, con la cabecera References, me inclinaría a que esté ausente para la publicación n.º 1 en un tema y que haga referencia al tema (por lo tanto, topic/#{topic_id}) y a la publicación a la que está respondiendo, si la hay.
De hecho, he estado investigando esto esta mañana y, sorprendentemente, la organización en hilo en una vista unificada funciona en Thunderbird para la mayoría de los casos, y creo que la cabecera 
\n\n[quote="Cameron Simpson, post:8, topic:233499, username:cameron-simpson"]\nEsto parece correcto. ¿Guarda este id con el registro de la base de datos para que las respuestas entrantes puedan vincularse al mensaje del foro antecedente?\n[/quote]\n\nLa respuesta es: depende. Si se crea una publicación en Discourse a partir de un correo electrónico entrante, como 
