Disculpas de antemano por el tono de lo que sigue. Sueno exasperado, porque estoy un poco exasperado.
Por Michael Brown vía Discourse Meta el 27 de julio de 2022 14:06:
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 (a efectos de esto, Para/De/Responder a/Cancelar suscripción/etc.) y un cuerpo diferente (está personalizado por usuario (¿creo? ¿Esto no sucede en el modo lista de correo?)).
¿Qué es exactamente el mensaje? Tratando 5322 como la verdad absoluta:
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” lo 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.
Bueno, desafortunadamente esto depende de una lectura demasiado literal, tal vez leyendo un contexto que no está ahí.
Cada mensaje de correo electrónico ve sus encabezados modificados a medida que el sistema de correo lo procesa. Si nada más, se agregan encabezados Received: en cada paso, y varios sistemas agregan varios encabezados que indican resultados de filtrado de spam y firmas. Ninguno de esos desencadena una modificación del message-id, y de hecho hacerlo haría que el message-id fuera totalmente disfuncional.
Con respecto al contenido, como ya se mencionó, casi todas las listas de correo agregan contenido al texto del cuerpo, generalmente un pie de página con un enlace a la página de administración de la lista o un enlace para cancelar la suscripción. Tampoco desencadenan un cambio de message-id.
De hecho, casi nada que reenvíe un mensaje cambia el message-id. Porque eso rompería el encadenamiento y la detección de duplicados para los clientes de usuario final.
Veo que sigues citando lo que yo estaba a punto de citar 
5322 también dice:
Hay muchas instancias en las que los mensajes se “modifican”, pero esas modificaciones 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 les 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 dichos campos de encabezado no cambia la identidad del mensaje y, por lo tanto, se conserva el campo “Message-ID:” original. 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 o no, no cualquier diferencia sintáctica particular que aparezca (o no aparezca) en el mensaje.
Supongo que se reduce a si el remitente del mensaje cambia cuando Discourse lo envía.
Creo que has malinterpretado las cosas aquí. Permíteme enfatizar:
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
El remitente es el autor, no un MTA como Discourse.
Si publico en Discourse por correo electrónico, quiero que mi mensaje llegue a los lectores tal como está, semánticamente hablando. Cualquier nota adicional como enlaces de cancelación de suscripción no cambia la semántica de lo que he dicho en mi mensaje.
Sigue siendo el mismo mensaje.
¿Quizás deberíamos usar Resent-Message-ID y sus amigos?
Absolutamente no. Son para que un usuario reenvíe un mensaje. Por ejemplo, si reenviara un mensaje a otra persona. No son para relés de correo (como listas y Discourse).
Siempre ha estado ahí, desde 822. Pero como dices más tarde, sí, se ha actualizado.
Ay. Pensé que era solo USENET en ese momento. Me retracto.
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 encabezado “Thread Identifier” 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”.
Me dice que los dos campos cubren la misma información:
Referencesmuestra un hilo lineal (generalmente) hasta el OPIn-Reply-Tomuestra el padre, e implica el mismo hilo en conjunto con los mensajes anteriores hasta el OP
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.
Esto no es complicado. El significado de los mensajes es el mismo, las personalizaciones son menores y semánticamente irrelevantes. No justifican message-ids nuevos o distintos.
Y sí, vi fuertes indicios durante las pruebas de que la determinación de spam estaría ligada a un Message-ID. Si se volvía a ver más tarde (mismo usuario o usuario diferente) sería mucho más probable que se marcara como spam.
¿Puedes mostrar algunas de estas instancias? Porque los message-ids permiten la deduplicación en el extremo del usuario final. Y ten en cuenta que muchas medidas “antispam” son basura mal concebida. La cantidad de cosas que he rechazado como posible spam por razones completamente espurias… romper el correo electrónico para solucionar un mal filtrado de spam roto es una mala elección.
Hasta el día de hoy, nunca pongo en copia a personas con direcciones de Gmail porque el filtrado de spam de Gmail me conoce y desecha las cosas. Si solo envío a la lista, lo reciben. Si pongo en copia su dirección de Gmail, (a) la marca como spam y (b) luego también marca el mensaje de la lista de correo como spam (¡mismo message-id!). El usuario final no ve mi mensaje. Esta lógica es completamente espuria e irreparable.
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.
Suspiro. Para todos los clientes de correo electrónico. Y una razón importante por la que la gente en el mundo de Python dice que simplemente no irá a Discourse es que el encadenamiento del lado del correo electrónico está roto. Muchas personas no usan foros, porque cada foro requiere que lo visiten. El correo electrónico les llega, pueden usar su lector preferido y su editor preferido, y el encadenamiento permite a las personas ver el flujo de la discusión claramente. Cuando funciona.
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ónMi mayor preocupación es la entregabilidad: es lo suficientemente difícil conseguir que el correo electrónico se entregue cuando no hay visibilidad de los principales proveedores.
Me gustaría ver evidencia. Las listas de correo hacen esto correctamente en todo el planeta. Discourse definitivamente y objetivamente rompe esto. Estoy tratando de arreglarlo.
Permítanme reiterar los dos problemas básicos aquí:
- El
In-Reply-ToyReferencesdel OP citan un “message-id” de “tema” “pre-OP” ficticio, por lo que ningún usuario de correo electrónico tiene un hilo con un mensaje de inicio (el OP): todo, incluido el OP, parece un seguimiento. - Los correos electrónicos recibidos a través de Discourse y los correos electrónicos recibidos directamente, por ejemplo, a través de CC, tienen message-ids diferentes a pesar de ser el mismo mensaje semánticamente hablando; esto rompe el encadenamiento y la deduplicación.
Pero sí veo un fuerte argumento para hacer que Discourse se comporte más como software de lista de correo en modo lista de correo. @martin, creo que no personalizamos el cuerpo del mensaje en modo lista de correo, ¿verdad? ¿Crees que tiene sentido adoptar un enfoque más estricto en torno a la preservación y reutilización de Message-IDs en modo lista de correo?
Hay gente en el mundo de Python que encontró el “modo lista de correo” como demasiado “manguera de incendios”. Quieren recibir correos electrónicos para temas específicos, pero no para todo. El manejo del message-id debería ser el mismo para todo el lado del correo electrónico.
Soy una persona de “modo lista de correo” en discuss.python.org. Pero lo activé aquí (discourse.org) y lo desactivé inmediatamente. Necesito el modo dirigido aquí.
