Obtenez le à Message-Id
partir de la page source
En plus de télécharger les archives du mois comme mentionné sur /webapps//a/23198/51862, vous pouvez également trouver le Message-Id
en inspectant la source de la page.
En haut de chaque page de message, par exemple http://lists.busybox.net/pipermail/buildroot/2018-March/214868.html, il y a un mailto:
lien qui s'affiche comme:
Ciro Santilli ciro.santilli at gmail.com
Si vous cliquez simplement dessus sur Chromium 64, Ubuntu 17.10, cela ne fonctionne pas: Thunderbird s'ouvre, sans le In-Reply-To
. Même comportement pour toutes les combinaisons de Firefox 58 et en configurant gmail comme gestionnaire d'e-mails que j'ai essayé.
Cependant, si vous ouvrez la source de la page ou utilisez la fonction de navigateur Inspect (Ctrl + Shift + I), nous pouvons voir que le lien complet est en fait:
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
et donc le In-Reply-To
est réellement là mais URL encodé! Nous pouvons ensuite utiliser un décodeur tel que: https://urldecode.org ou des outils CLI qui nous donnent le bon Message-Id
:
<20180303072704.11166-1-ciro.santilli@gmail.com>
Définissez manuellement l'en- In-Reply-To
tête sur celui que Message-Id
nous avons trouvé
Une fois que nous avons l'ID du message, nous devons maintenant trouver un client qui nous permet de le définir.
Méthodes que j'ai testées sur mon compte gmail:
Je n'ai pas pu trouver une bonne méthode pour les clients suivants:
Normes
Le RFC lui-même mentionne que In-Reply-To
dans les mailto
liens https://tools.ietf.org/html/rfc1738 :
Une utilisation intéressante de votre URL mailto est lors de la navigation dans les archives de messages. Chaque message parcouru peut contenir une URL mailto comme:
<mailto:foobar@example.com?In-Reply-
To=%3c3469A91.D10AF4C@example.com>
et c'est formidable que les développeurs GNU Mailman en aient profité, mais je me demande quel composant ne fonctionne pas correctement pour que cela fonctionne.
Confusément, le même RFC dit également:
4. En-têtes dangereux
L'agent utilisateur interprétant une URL mailto DEVRAIT choisir de ne pas créer de message si l'un des en-têtes est considéré comme dangereux; il peut également choisir de créer un message avec uniquement un sous-ensemble des en-têtes indiqués dans l'URL. Seuls les en-têtes Sujet, Mots-clés et Corps sont à la fois sûrs et utiles.
Le créateur d'une URL mailto ne peut pas s'attendre à ce que le résolveur d'une URL comprenne mieux que les en-têtes "sujet" et "corps". Les clients qui résolvent les URL mailto en messages électroniques doivent pouvoir créer correctement des messages électroniques conformes à la RFC 822 en utilisant les en-têtes "sujet" et "corps".
alors peut-être que c'est pourquoi de nombreux clients ne le soutiennent pas?
Voir également: /programming/4782068/can-i-set-subject-content-of-email-using-mailto/41365892#41365892
La prochaine chose que vous voudrez savoir, c'est comment appliquer les ensembles de correctifs que d'autres personnes ont envoyés pour les tester localement: /programming/5062389/getting-started-with-git-am Spoiler: c'est une douleur / annulable également.