List-Unsubscribe et désabonnement en un clic (RFC 2369 et RFC 8058)

Deux RFC définissent le mécanisme standard de désabonnement lisible par machine :

• La RFC 2369 (1998) définit les champs d’en-tête List-*, dont List-Unsubscribe.
• La RFC 8058 (2017) ajoute List-Unsubscribe-Post, qui transforme la variante HTTPS en une action en un clic que les clients de messagerie peuvent effectuer pour le compte de l’utilisateur, sans charger de page web.

Ensemble, elles font fonctionner le lien « Se désabonner » (Unsubscribe) que Gmail, Yahoo, Apple Mail et Outlook.com affichent à côté du nom de l’expéditeur.

RFC 2369 : les champs d’en-tête List-*

La RFC 2369 définit six champs d’en-tête pour les messages distribués par une liste de diffusion :

Règles de syntaxe

• Le contenu des champs se compose d’URL entre chevrons : <mailto:...> ou <http://...>. Les espaces à l’intérieur des chevrons sont ignorés ; les générateurs ne doivent pas insérer d’espaces entre les chevrons, mais les clients devraient tolérer les entrées mal formatées.
• Plusieurs URL alternatives PEUVENT être fournies, sous la forme d’une liste d’URL entre chevrons séparées par des virgules. L’ordre exprime la préférence, de gauche à droite : un client utilise le protocole le plus à gauche qu’il prend en charge (par exemple HTTPS d’abord, mailto: en solution de repli).
• Des commentaires facultatifs entre parenthèses peuvent suivre une URL : List-Post: NO (posting not allowed on this list).
• Au plus une occurrence de chaque champ par message.
• Les champs DOIVENT être générés uniquement par le système de la liste ou d’envoi, jamais par les utilisateurs finaux.
• Les champs implémentés pour une liste DEVRAIENT figurer dans tous les messages distribués par cette liste.
• Règles d’analyse côté client : si le contenu du champ commence par autre chose que <, le champ DEVRAIT être ignoré ; les caractères qui suivent un > fermant sont ignorés, sauf si le caractère suivant (hors espaces et commentaires) est une virgule ; un élément séparé par des virgules qui n’est pas une URL entre chevrons fait ignorer tout le reste du champ.
• Les sous-listes qui redistribuent les messages d’une liste parente devraient remplacer les champs List-Help, List-Subscribe, List-Unsubscribe et List-Owner de la liste parente par les leurs, et conserver List-Archive, sauf si elles fournissent le leur.

Exemples (tirés de la RFC)

List-Unsubscribe: <mailto:list@host.com?subject=unsubscribe>
List-Unsubscribe: <http://www.host.com/list.cgi?cmd=unsub&lst=list>,
    <mailto:list-request@host.com?subject=unsubscribe>
List-Help: <http://www.host.com/list/>, <mailto:list-info@host.com>
List-Subscribe: <http://www.host.com/list.cgi?cmd=sub&lst=list>,
    <mailto:list-manager@host.com?body=subscribe%20list>
List-Post: <mailto:list@host.com>
List-Owner: <mailto:listmom@host.com>
List-Archive: <http://www.host.com/list/archive/> (Web Archive)

Pour les URL mailto:, les clients sont censés afficher une boîte de dialogue de confirmation (destinataire et commande) avant l’envoi.

RFC 8058 : désabonnement en un clic (List-Unsubscribe-Post)

Le problème que résout la RFC 8058 : une simple URL HTTPS dans List-Unsubscribe ne peut pas être appelée automatiquement sans risque, car les scanners antispam, les outils de préchargement de liens et les proxys de sécurité suivent les liens GET, ce qui désabonnerait des utilisateurs qui n’ont rien demandé. La RFC 8058 définit un signal fondé sur POST, que seule une action délibérée dans le client de messagerie peut déclencher.

Syntaxe de l’en-tête

list-unsubscribe-post = "List-Unsubscribe-Post:" 0*1WSP postarg CRLF
postarg               = "List-Unsubscribe=One-Click"

La valeur de l’en-tête est exactement List-Unsubscribe=One-Click : rien d’autre n’est valide.

Exigences envers l’expéditeur

Si la signature DKIM exigée est absente ou invalide, le serveur de réception NE DEVRAIT PAS proposer le désabonnement en un clic : c’est ce qui empêche un attaquant d’injecter de faux en-têtes de désabonnement.

Sémantique du POST (ce qu’envoie le fournisseur de messagerie)

Lorsque l’utilisateur clique sur la commande de désabonnement de son client de messagerie, le serveur de réception envoie une requête HTTPS POST à l’URI indiquée dans List-Unsubscribe, avec pour corps la paire clé-valeur de List-Unsubscribe-Post :

• Content-Type : multipart/form-data (DEVRAIT) ou application/x-www-form-urlencoded (PEUT).
• Corps : l’unique paire List-Unsubscribe=One-Click.
• La requête NE DOIT PAS inclure de cookies, d’autorisation HTTP ni aucune autre information de contexte : le point de terminaison ne peut donc pas s’appuyer sur un état de session, seulement sur l’URI elle-même.
• Le serveur de réception NE DOIT PAS effectuer le POST sans le consentement de l’utilisateur (c’est-à-dire uniquement sur une action explicite de l’utilisateur, jamais par anticipation).

Exemples (tirés de la RFC)

List-Unsubscribe: <https://example.com/unsubscribe/opaquepart>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

POST /unsubscribe/opaquepart HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 26

List-Unsubscribe=One-Click

Avec une alternative mailto: et multipart/form-data :

List-Unsubscribe:
    <mailto:listrequest@example.com?subject=unsubscribe>,
    <https://example.com/unsubscribe.html/opaque123456789>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

POST /unsubscribe.html/opaque=123456789 HTTP/1.1
Host: example.com
Content-Type: multipart/form-data; boundary=---FormBoundaryjWmhtjORrn
Content-Length: 124

---FormBoundaryjWmhtjORrn
Content-Disposition: form-data; name="List-Unsubscribe"

One-Click
---FormBoundaryjWmhtjORrn--

Modèle de sécurité

• Limiter le corps du POST à une seule paire fixe empêche de détourner l’en-tête pour déclencher des soumissions de formulaire arbitraires.
• Exclure les cookies et l’autorisation empêche de relier le désabonnement aux autres activités web de l’utilisateur.
• Comme avec le List-Unsubscribe classique, toute personne qui dispose d’une copie du message peut désabonner le destinataire : l’élément opaque de l’URI réduit le risque, il ne l’élimine pas.

Pourquoi Gmail et Yahoo l’imposent

Depuis février 2024, Gmail et Yahoo exigent des expéditeurs de gros volumes (seuil de Gmail : environ 5 000 messages ou plus par jour vers ses utilisateurs) qu’ils intègrent le désabonnement en un clic de la RFC 8058 à leurs messages commerciaux et promotionnels, et qu’ils traitent les désabonnements dans un délai de deux jours. Les raisons découlent directement des fondamentaux de la délivrabilité (voir Fondamentaux de la délivrabilité des emails) :

• Un désabonnement sans friction est l’alternative au bouton « Signaler comme spam » (Report spam). Chaque utilisateur qui se désabonne au lieu de se plaindre protège votre taux de plaintes (Gmail : maintenir le taux de spam sous 0,10 %, et ne jamais dépasser 0,30 %).
• L’exigence de couverture par DKIM rattache la promesse de désabonnement à un domaine authentifié, en complément de l’alignement DMARC.
• Comme le POST ne transporte ni cookies ni contexte, l’honorer exige, côté expéditeur, une infrastructure qui associe réellement le jeton opaque à une inscription effective en liste de suppression : un bon indicateur indirect de la maîtrise de l’hygiène de base de données.

Liste de contrôle de mise en œuvre pour l’expéditeur

1. Ajoutez les deux en-têtes à chaque message commercial ou de liste ; conservez mailto: comme URI de repli à côté de l’URI HTTPS.
2. Signez avec DKIM et incluez les deux en-têtes dans la liste h= de la signature.
3. Rendez le point de terminaison idempotent, sans redirection et instantané : placement en liste de suppression dès le POST, sans connexion, sans « êtes-vous sûr ? ».
4. Versez les désabonnements en un clic dans la même liste de suppression que les plaintes issues des feedback loops ; traitez-les dans un délai de 48 heures au plus tard.
5. Conservez aussi le lien de désabonnement dans le corps du message : les en-têtes le complètent, ils ne le remplacent pas.