Les en-têtes List-Unsubscribe et de désabonnement en un clic (RFC 2369 et RFC 8058)

Ce que c'est

La RFC 2369 définit des champs d'en-tête que les logiciels de liste ajoutent, afin que les clients de messagerie puissent proposer des actions de liste sans analyser le corps : List-Help, List-Subscribe, List-Unsubscribe, List-Post, List-Owner, List-Archive, chacun contenant une ou plusieurs URI, généralement mailto: et éventuellement HTTP. La RFC 8058 ajoute le désabonnement en un clic : le message porte List-Unsubscribe avec une URI HTTPS unique et List-Unsubscribe-Post avec la valeur unique List-Unsubscribe=One-Click. Un destinataire se désabonne en envoyant une requête HTTPS POST vers cette URI, avec cette paire clé/valeur comme corps. La RFC exige que l'URI identifie à elle seule le destinataire et la liste (il n'y a pas d'arguments POST supplémentaires), exige une signature DKIM valide couvrant les deux en-têtes, et interdit de répondre au POST par une redirection. Les directives de Google pour les expéditeurs imposent aux messages marketing et aux messages sur abonnement provenant d'expéditeurs en masse (plus de 5 000 messages par jour) de prendre en charge le désabonnement en un clic et d'inclure aussi, dans le corps, un lien de désabonnement clairement visible.

Pourquoi c'est important

Les destinataires qui ne trouvent pas de contrôle de désabonnement appuient à la place sur « signaler comme spam », et ce sont les plaintes qui font filtrer un expéditeur. Un contrôle fondé sur un en-tête permet au client de proposer le désabonnement juste à côté du message, et permet aux serveurs destinataires de le traiter en arrière-plan. Pour les expéditeurs en masse, ce n'est plus une politesse mais une condition d'admission.

Comment l'appliquer

• Émettre les deux en-têtes sur chaque message marketing ou d'abonnement ; en priver le courrier transactionnel (reçus, réinitialisations de mot de passe), puisqu'il n'y a rien dont se désabonner.
• Placer dans l'URI un jeton opaque qui correspond à (destinataire, liste) ; ne pas exiger de connexion, de page de confirmation ni de champs de formulaire supplémentaires sur le chemin du POST.
• Répondre directement au POST par un statut de succès, jamais par une redirection, et le traiter de façon idempotente ; la même URI peut servir une page lisible par un humain en GET pour les personnes qui cliquent sur le lien.
• Inclure les deux en-têtes dans le tag DKIM h= et vérifier la signature sur un message ayant traversé tout le pipeline d'envoi ; la RFC indique que les destinataires ne devraient pas proposer le clic unique sans cela.
• Conserver une alternative mailto: dans List-Unsubscribe, que la RFC 2369 recommande pour les clients sans HTTP.
• Journaliser les désabonnements avec leur source (POST d'en-tête, page, réponse) et arrêter l'envoi immédiatement ; un message « final » envoyé en retard après un refus est une plainte qui ne demande qu'à arriver.

Pièges

Un point d'accès qui n'accepte que le GET (les clients font un POST). Rediriger le POST vers une page de connexion ou de préférences. Des jetons qui expirent avant la lecture d'une newsletter. Traiter la demande comme une simple suggestion et continuer à envoyer des « mises à jour importantes ». Ajouter les en-têtes après la signature DKIM, ce qui invalide la signature ou les laisse hors de sa couverture.