Ottieni il Message-Id
dalla sorgente della pagina
Oltre a scaricare gli archivi del mese, come menzionato su /webapps//a/23198/51862 , puoi anche trovare Message-Id
ispezionando l'origine della pagina.
Nella parte superiore di ogni pagina di messaggio, ad esempio http://lists.busybox.net/pipermail/buildroot/2018-March/214868.html c'è un mailto:
link che mostra come:
Ciro Santilli ciro.santilli at gmail.com
Se fai semplicemente clic su di esso su Chromium 64, Ubuntu 17.10, non funziona: Thunderbird si apre, senza il In-Reply-To
. Lo stesso comportamento per tutte le combinazioni di Firefox 58 e l' impostazione di Gmail del mio gestore di posta elettronica che ho provato.
Tuttavia, se apri l'origine della pagina o usi la funzione Ispeziona browser (Ctrl + Maiusc + I), possiamo vedere che il link completo è effettivamente:
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
e così In-Reply-To
è effettivamente lì ma URL codificato! Possiamo quindi usare un decodificatore come: https://urldecode.org o strumenti CLI che ci danno il corretto Message-Id
:
<20180303072704.11166-1-ciro.santilli@gmail.com>
Imposta manualmente l' In-Reply-To
intestazione su che Message-Id
abbiamo trovato
Una volta che abbiamo l'ID del messaggio, ora dobbiamo trovare un client che ci permetta di impostarlo.
Metodi che ho testato sul mio account Gmail:
Non sono riuscito a trovare un buon metodo per i seguenti clienti:
Standards
Lo stesso RFC menziona che In-Reply-To
nei mailto
link https://tools.ietf.org/html/rfc1738 :
Un uso interessante del tuo URL mailto è quando navighi negli archivi dei messaggi. Ogni messaggio consultato potrebbe contenere un URL mailto come:
<mailto:foobar@example.com?In-Reply-
To=%3c3469A91.D10AF4C@example.com>
ed è bello che gli sviluppatori GNU Mailman ne abbiano approfittato, ma mi chiedo quale componente non funzioni correttamente per farlo funzionare.
Confusamente, lo stesso RFC dice anche:
4. Intestazioni non sicure
L'agente utente che interpreta un URL mailto DOVREBBE scegliere di non creare un messaggio se una delle intestazioni è considerata pericolosa; può anche scegliere di creare un messaggio con solo un sottoinsieme delle intestazioni fornite nell'URL. Solo le intestazioni Oggetto, Parole chiave e Corpo sono ritenute sicure e utili.
Il creatore di un URL mailto non può aspettarsi che il risolutore di un URL comprenda più delle intestazioni "subject" e "body". I client che risolvono gli URL mailto in messaggi di posta dovrebbero essere in grado di creare correttamente messaggi di posta conformi a RFC 822 utilizzando le intestazioni "oggetto" e "corpo".
quindi forse è per questo che molti clienti non lo supportano?
Vedi anche: /programming/4782068/can-i-set-subject-content-of-email-using-mailto/41365892#41365892
La prossima cosa che vorresti sapere è come applicare i set di patch che altre persone hanno inviato per testarli localmente: /programming/5062389/getting-started-with-git-am Spoiler: è un dolore / anche annullabile.