Obtenga el Message-Idde la fuente de la página
Además de descargar los archivos del mes como se menciona en /webapps//a/23198/51862 , también puede encontrarlos Message-Idinspeccionando la fuente de la página.
En la parte superior de cada página de mensajes, por ejemplo, http://lists.busybox.net/pipermail/buildroot/2018-March/214868.html hay un mailto:enlace que se muestra como:
Ciro Santilli ciro.santilli at gmail.com
Si solo hace clic en Chromium 64, Ubuntu 17.10, no funciona: Thunderbird se abre, sin el In-Reply-To. El mismo comportamiento para todas las combinaciones de Firefox 58 y la configuración de gmail como mi controlador de correo electrónico que he probado.
Sin embargo, si abre la fuente de la página o usa la función Inspeccionar navegador (Ctrl + Shift + I), podemos ver que el enlace completo es en realidad:
mailto:buildroot%40busybox.net?Subject=Re%3A%20%5BBuildroot%5D%20%5BPATCH%5D%20Fix%20%22Incorrect%20selection%20of%20kernel%20headers%3A%0A%20expected%204.11.x%2C%20got%204.15.x%22%20for%20qemu_x86_64_defconfig&In-Reply-To=%3C20180303072704.11166-1-ciro.santilli%40gmail.com%3E
¡y entonces In-Reply-Toestá realmente allí pero codificado en URL! Luego podemos usar un decodificador como: https://urldecode.org o herramientas de CLI que nos da la correctaMessage-Id :
<20180303072704.11166-1-ciro.santilli@gmail.com>
Configurar manualmente el In-Reply-To encabezado al Message-Idque encontramos
Una vez que tengamos el ID del mensaje, ahora necesitamos encontrar un cliente que nos permita configurarlo.
Métodos que he probado en mi cuenta de gmail:
No pude encontrar un buen método para los siguientes clientes:
Normas
El propio RFC menciona que In-Reply-Toen los mailtoenlaces https://tools.ietf.org/html/rfc1738 :
Un uso interesante de su URL mailto es cuando navega por archivos de mensajes. Cada mensaje examinado puede contener una URL mailto como:
<mailto:foobar@example.com?In-Reply-
To=%3c3469A91.D10AF4C@example.com>
y es genial que los desarrolladores de GNU Mailman lo hayan aprovechado, pero me pregunto qué componente no funciona correctamente para que esto funcione.
Confusamente, el mismo RFC también dice:
4. Encabezados inseguros
El agente de usuario que interpreta una URL mailto DEBE elegir no crear un mensaje si alguno de los encabezados se considera peligroso; También puede optar por crear un mensaje con solo un subconjunto de los encabezados que figuran en la URL. Se cree que solo los encabezados de Asunto, Palabras clave y Cuerpo son seguros y útiles.
El creador de una URL mailto no puede esperar que el solucionador de una URL comprenda más que los encabezados de "asunto" y "cuerpo". Los clientes que resuelven URL de mailto en mensajes de correo deberían poder crear correctamente mensajes de correo compatibles con RFC 822 utilizando los encabezados "asunto" y "cuerpo".
Entonces, ¿quizás por eso muchos clientes no lo admiten?
Ver también: /programming/4782068/can-i-set-subject-content-of-email-using-mailto/41365892#41365892
Lo siguiente que querrá saber es cómo aplicar los conjuntos de parches que otras personas han enviado para probarlos localmente: /programming/5062389/getting-started-with-git-am Spoiler: es un dolor / deshacer también.