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

Si vous envoyez des messages en nombre ou des emails marketing, le lien « Se désabonner » (Unsubscribe) que Gmail, Yahoo, Apple Mail et Outlook.com affichent à côté du nom de l’expéditeur provient d’en-têtes que vous ajoutez à chaque message. Deux RFC définissent ce mécanisme standard de désabonnement lisible par une 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 l’utilisateur, sans charger de page web.

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 de chaque champ est une ou plusieurs URL entre chevrons : <mailto:...> ou <http://...>. Les espaces à l’intérieur des chevrons sont ignorés. Les systèmes qui génèrent les champs ne doivent pas mettre 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 indique 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, avec mailto: en solution de repli).
• Des commentaires entre parenthèses peuvent suivre une URL : List-Post: NO (posting not allowed on this list).
• Un message peut contenir au plus une occurrence de chaque champ.
• 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 que cette liste distribue.
• Règles pour les clients qui analysent les champs : 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 qui n’est ni un espace ni une partie d’un commentaire est une virgule. Un élément séparé par des virgules qui n’est pas une URL entre chevrons fait ignorer le reste du champ.
• Une sous-liste qui redistribue les messages d’une liste parente devrait remplacer les champs List-Help, List-Subscribe, List-Unsubscribe et List-Owner de la liste parente par les siens, et conserver List-Archive, sauf si elle fournit le sien.

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 (avec le destinataire et la commande) avant l’envoi.

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

Une simple URL HTTPS dans List-Unsubscribe ne peut pas être ouverte automatiquement sans risque. 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 jamais demandé à partir. La RFC 8058 résout ce problème. Le signal que définit la RFC 8058 est fondé sur POST, et seule une action délibérée dans le client de messagerie le produit.

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, et 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 dans le client, le serveur de réception envoie une requête HTTPS POST à l’URI indiquée dans List-Unsubscribe, avec pour corps la clé et la 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 une session, seulement sur l’URI elle-même.
• Le serveur de réception NE DOIT PAS envoyer le POST sans le consentement de l’utilisateur. Il ne l’envoie qu’après 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 d’utiliser 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. La partie opaque de l’URI réduit ce risque, mais ne l’élimine pas.

Pourquoi Gmail et Yahoo l’imposent

Depuis février 2024, Gmail et Yahoo exigent des expéditeurs de gros volumes (le seuil de Gmail est d’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 bases 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 demande de maintenir le taux de spam sous 0,10 % et de ne jamais le laisser dépasser 0,30 %).
• L’exigence que DKIM couvre les en-têtes rattache le 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 vraie inscription en liste de suppression. C’est donc un bon indicateur de la compétence d’un expéditeur dans la gestion de ses listes.

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, et 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é : placez l’adresse en liste de suppression dès le POST, sans connexion et sans étape « ê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, et traitez-les dans un délai de 48 heures au plus tard (l’exigence de Gmail et Yahoo décrite plus haut).
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.

Ce qu’ajoutent les Sender Best Common Practices du M3AAWG

Le Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG) décrit les pratiques du secteur en matière de désabonnement dans ses Sender Best Common Practices (version 4.0, août 2026, section 4.6). La version 4.0 fait du désabonnement en un clic une exigence des recommandations du M3AAWG lui-même, en s’appuyant sur les règles des grands fournisseurs de messagerie :

• Le désabonnement en un clic est une exigence. Pour répondre aux exigences mises à jour des grands fournisseurs de messagerie, les expéditeurs « doivent mettre en œuvre le désabonnement en un clic (List-Unsubscribe-Post) dans les en-têtes, comme le décrit la RFC 8058 » (section 4.6, point 6c). Le même point indique toujours que les expéditeurs devraient adopter l’en-tête List-Unsubscribe de la RFC 2369 lui-même.
• Gardez l’adresse hors du lien. Le lien de désabonnement ne devrait pas afficher l’adresse email de l’abonné, et devrait utiliser une référence encodée plutôt que du texte en clair (point 14). La section 2.8 étend cette règle à toutes les URL d’action d’un message, y compris les liens de suivi et de préférences. L’adresse ne devrait apparaître ni en clair ni sous un encodage facile à inverser, comme le base64. Une valeur chiffrée, ou un identifiant sans rapport avec le destinataire que seul l’expéditeur peut faire correspondre, est bien préférable. La partie opaque d’une URI RFC 8058 fonctionne déjà ainsi.
• Sans délai, mais sans échéance chiffrée. Les expéditeurs doivent traiter chaque demande de désabonnement sans délai (point 2), et devraient indiquer aux destinataires, pendant la démarche, le délai de retrait et les listes concernées (point 3). Le M3AAWG ne fixe aucun nombre de jours. Les délais de 48 heures et de deux jours cités sur cette page viennent de Gmail et Yahoo, pas du M3AAWG.
• Aucune connexion. Les abonnés doivent pouvoir se désabonner sans se connecter à un centre de préférences ni passer aucun autre contrôle de sécurité (point 12). Cela correspond à la règle de la RFC 8058 selon laquelle le point de terminaison effectue l’action sans autre interaction.