From bc1d70343807104ccf64b6bde9b2db54270203ff Mon Sep 17 00:00:00 2001 From: neodarz Date: Fri, 10 Mar 2017 11:58:22 +0100 Subject: Initiale release --- ...eClick_Functionality_for_List_Email_Headers.txt | 126 +++++++++++++++++++++ 1 file changed, 126 insertions(+) create mode 100644 RFC_8058_Signaling_OneClick_Functionality_for_List_Email_Headers.txt (limited to 'RFC_8058_Signaling_OneClick_Functionality_for_List_Email_Headers.txt') diff --git a/RFC_8058_Signaling_OneClick_Functionality_for_List_Email_Headers.txt b/RFC_8058_Signaling_OneClick_Functionality_for_List_Email_Headers.txt new file mode 100644 index 0000000..ed6d1fd --- /dev/null +++ b/RFC_8058_Signaling_OneClick_Functionality_for_List_Email_Headers.txt @@ -0,0 +1,126 @@ +Titre: RFC 8058: Signaling One-Click Functionality for List Email Headers +Auteur: +Date: Tue 31 Jan 2017 01:00:00 +0100 +Lien: https://www.bortzmeyer.org/8058.html + +Le RFC 2369 décrit des en-têtes du courrier électronique qui indiquent, entre +autres, comment se désabonner d'une liste de diffusion (en-tête +List-Unsubscribe:, qui indique des URI à activer pour se désabonner). Cela peut +permettre des désabonnements sans interaction explicite avec l'utilisateur : le +MUA voit cette en-tête, propose un bouton « Désabonnement » à l'utilisateur, et +le MUA effectue la requête (par exemple HTTP) tout seul. L'inconvénient est que +certains logiciels (par exemple des anti-spam) visitent automatiquement tous +les liens hypertexte présents dans les messages, et risquent alors de +désabonner l'abonné accidentellement. Pour éviter cela, la page pointée par +l'URI présent dans List-Unsubscribe: n'est en général pas « one-click » : il +faut une action explicite une fois cette page affichée. Ce nouveau RFC propose +des ajouts à List-Unsubscribe: pour indiquer qu'un désabonnement one-click est +possible. + +Voici un exemple de cet en-tête traditionnel List-Unsubscribe: dans une liste +de diffusion IETF : + + +List-Unsubscribe: <>https://www.ietf.org/mailman/options/ietf>, + <>mailto:ietf-request@ietf.org?subject=unsubscribe> + +La page indiquée dans l'URI HTTPS est une landing page : elle ne désabonne pas +directement, il faut indiquer son adresse et sélectionner le bouton Unsubscribe +. C'est acceptable quand l'utilisateur est un humain, mais pas dans les cas où +il n'y a pas d'interaction possible. Imaginons un logiciel qui traite +automatiquement les messages après le départ ou le décès d'un utilisateur, et +qui veut donc le désabonner proprement de toutes les listes où il était abonné +avec cette adresse désormais invalide. Ce logiciel doit pouvoir fonctionner +sans intervention humaine, donc sans analyser une page HTML compliquée. + +À noter que l'en-tête List-Unsubscribe: ci-dessus, comme dans la plupart des +cas, propose également un URI de plan mailto:, déclenchant l'envoi d'un message +par courrier électronique. La plupart des services qui envoient de grosses +quantités de message (les hébergeurs de listes de diffusion à grand volume) ont +du mal à gérer le flot de messages de désinscription (ils sont optimisés pour +envoyer beaucoup, pas pour recevoir beaucoup), et ce RFC ne prend donc en +compte que les URI de plan https:. + +La section 1 résume le cahier des charges de la solution présentée ici : + + * Permettre aux émetteurs de courrier de signaler de manière standard et + non-ambigue qu'on peut se désabonner en un seul clic (« one-click »), + * Permettre aux auteurs de MUA de fournir une interface simple (par exemple + un bouton « Désabonnement immédiat », lorsque le message lu est signalé + comme le permettant), + * Permettre aux utilisateurs de se désabonner sans quitter leur MUA, sans + avoir à basculer vers une page Web avec des instructions spécifiques (et, + notre RFC oublie de le dire, page Web qui est souvent conçue pour + décourager le désabonnement de la newsletter à la con). + +La section 3 du RFC spécifie la solution retenue. Elle consiste dans l'ajout +d'un nouvel en-tête, List-Unsubscribe-Post:, dont le contenu est un couple +clé=valeur, List-Unsubscribe=One-Click. (Ce nouvel en-tête a été ajouté dans le +registre IANA[1].) Par exemple, l'en-tête montré plus haut deviendrait : + + +List-Unsubscribe: <>https://www.ietf.org/mailman/options/ietf?id=66fd1aF64>, + <>mailto:ietf-request@ietf.org?subject=unsubscribe> +List-Unsubscribe-Post: List-Unsubscribe=One-Click + +Cela indiquerait clairement que le désabonnement en un clic est possible. Le +MUA, s'il désire effectuer le désabonnement, va alors faire une requête HTTPS +de méthode POST, en mettant dans le corps de la requête le contenu de l'en-tête +List-Unsubscribe-Post:. Le serveur HTTPS, s'il voit ce +List-Unsubscribe=One-Click dans la requête, doit exécuter la requête sans poser +de questions supplémentaires (le but étant de faire un désabonnement en un seul +clic). + +Notez qu'il faut indiquer quelque part l'adresse à désabonner, le serveur HTTP +ne peut pas la deviner autrement. Pour rendre plus difficile la création de +fausses instructions de désabonnement, cela se fait indirectement, via une +donnée opaque, comprise seulement du serveur (le id dans l'exemple hypothétique +ci-dessus). + +Les données contenues dans le List-Unsubscribe-Post: doivent idéalement être +envoyées avec le type MIME multipart/form-data (RFC 7578), et, sinon, en +application/x-www-form-urlencoded, comme le ferait un navigateur Web. Bien sûr, +le MUA doit avoir la permission de l'utilisateur pour effectuer ce +désabonnement (on est en « un seul clic », pas en « zéro clic »). + +Au fait, pourquoi la méthode POST ? GET ne peut pas modifier l'état du serveur +et PUT ou DELETE sont rarement accessibles. + +Le courrier électronique n'étant pas vraiment sécurisé, il y a un risque de +recevoir des messages avec un List-Unsubscribe-Post: mensonger. C'est pourquoi +le RFC demande (section 4) qu'il y ait un minimum d'authentification du +message. La seule méthode d'authentification décrite est DKIM (RFC 6376), avec +une étiquette d= identifiant le domaine. La signature DKIM doit évidemment +inclure dans les en-têtes signés les List-Unsubscribe: et +List-Unsubscribe-Post: dans l'étiquette DKIM h=. + +Avec l'exemple plus haut, la requête HTTP POST ressemblerait à : + +POST /mailman/options/ietf?id=66fd1aF64 HTTP/1.1 +Host: www.ietf.org +Content-Type: multipart/form-data; boundary=---FormBoundaryjWmhtjORrn +Content-Length: 124 + +---FormBoundaryjWmhtjORrn +Content-Disposition: form-data; name="List-Unsubscribe" + +One-Click +---FormBoundaryjWmhtjORrn-- + +La section 6 de notre RFC décrit les éventuels problèmes de sécurité. En gros, +il en existe plusieurs, mais tous sont en fait des problèmes génériques du +courrier électronique, et ne sont pas spécifiques à cette nouvelle solution. +Par exemple, un spammeur pourrait envoyer plein de messages ayant l'en-tête +List-Unsubscribe-Post:, pour faire générer plein de requêtes POST vers le +pauvre serveur. Mais c'est déjà possible aujourd'hui en mettant des URI dans un +message, avec les logiciels qui vont faire des GET automatiquement. + +Je n'ai pas encore vu cet en-tête List-Unsubscribe-Post: apparaitre dans de +vrais messages. + +Un des auteurs du RFC a écrit un bon résumé de son utilité[2], article qui +explique bien comment fonctionne le courrier aujourd'hui. + +Liens: +[1]: http://www.iana.org/assignments/message-headers/message-headers.xml#perm-headers (lien) +[2]: http://www.circleid.com/posts/20170126_one_click_unsubscription/ (lien) -- cgit v1.2.1