Les outils de sécurité automatisés peuvent ouvrir les liens dans les e-mails entrants. Une simple visite de lien ne constitue donc pas une preuve suffisante qu'un destinataire souhaite se désabonner.
Comment le désabonnement en un clic distingue-t-il une demande de désabonnement d'une visite de lien ?
Le désabonnement en un clic utilise une requête POST HTTP après le consentement du destinataire, au lieu de traiter un lien consulté comme un opt-out.
RFC 8058 exige que le système récepteur obtienne le consentement de l'utilisateur avant d'effectuer cette requête.
L'expéditeur peut alors traiter l'opt-out sans connexion ni page de confirmation. Un désabonnement facile offre aussi aux destinataires une alternative au signalement des messages indésirables comme spam.
Quels en-têtes le message doit-il contenir ?
Le message nécessite un en-tête List-Unsubscribe et un en-tête List-Unsubscribe-Post.
Le premier fournit la destination de désabonnement. Le second contient la valeur exacte List-Unsubscribe=One-Click. Les directives pour les expéditeurs de Google montrent cette paire :
List-Unsubscribe-Post: List-Unsubscribe=One-Click
List-Unsubscribe: <https://solarmora.com/unsubscribe/example>Utilisez une URL HTTPS pour la destination afin de protéger les requêtes de désabonnement contre l'interception. Des destinations supplémentaires non HTTP, comme une adresse mailto, sont autorisées.
Signez les deux en-têtes avec DKIM. Incluez-les dans la liste h= des en-têtes couverts par la signature. Sans la signature valide requise, RFC 8058 déconseille aux récepteurs de proposer le contrôle de désabonnement en un clic. Fournir les en-têtes seuls ne garantit donc pas l'affichage d'un bouton.
Que doit accepter l'endpoint de désabonnement ?
L'endpoint doit accepter le POST de désabonnement en un clic sans exiger de connexion, de cookies ni d'autorisation HTTP. Le système de messagerie récepteur effectue la requête sans la session web du destinataire.
Son URL doit identifier le destinataire et la liste dont il doit être retiré, car aucune session ne fournit ce contexte. Le corps du POST transporte la paire fixe List-Unsubscribe=One-Click.
Utilisez un identifiant difficile à falsifier dans l'URL, car une adresse prévisible pourrait permettre à quelqu'un de désabonner un autre destinataire. Validez cet identifiant avant d'appliquer la requête.
L'expéditeur ne doit pas retourner une redirection HTTPS. Une redirection peut modifier le traitement d'un POST, donc l'endpoint publié doit traiter la requête directement. Une réponse de redirection 3xx ne satisfait donc pas cette exigence.
Que se passe-t-il si un pare-feu bloque la requête ?
Une requête bloquée peut laisser l'expéditeur responsable d'un désabonnement non traité.
Le tableau de bord de conformité de Google comptabilise les requêtes de désabonnement réussies même quand un intermédiaire les empêche d'atteindre vos serveurs.
Un challenge anti-bot nécessitant une session navigateur entre en conflit avec un POST anonyme de désabonnement en un clic. Configurez les règles d'accès de l'endpoint pour que les requêtes légitimes puissent l'atteindre. Un journal applicatif vide ne prouve pas qu'aucun destinataire n'a essayé de se désabonner.
Le désabonnement en un clic remplace-t-il le lien dans le corps du message ?
Non, Google et Yahoo exigent aussi un lien de désabonnement visible dans le corps des messages marketing et des messages par abonnement.
Google exige la méthode RFC 8058 pour le contrôle basé sur les en-têtes. Les recommandations de Yahoo préconisent cette méthode et acceptent aussi mailto dans l'en-tête list-unsubscribe.
Le lien dans le corps du message offre aux destinataires un autre moyen de demander leur retrait. Il reste nécessaire même quand un client de messagerie affiche son propre contrôle.
Dans quel délai devez-vous traiter la requête ?
Google et Yahoo exigent le traitement des requêtes de désabonnement sous deux jours.
Google exprime ce délai en 48 heures dans son tableau de bord de conformité. Une requête effectuée lundi à midi doit donc être traitée au plus tard mercredi à midi.
Le délai concerne le retrait du destinataire de la liste. Un endpoint fonctionnel qui laisse le destinataire abonné au-delà de ce délai ne satisfait pas l'exigence de traitement.
Comment utiliser la gestion du désabonnement de Bird ?
Vous classez un envoi comme marketing pour que Bird fournisse sa gestion de désabonnement intégrée.
Le champ category de API accepte marketing pour le courrier promotionnel ou transactional pour les messages opérationnels. Sans catégorie explicite, un envoi utilisant un modèle réutilisable hérite de sa classification. Les autres envois prennent par défaut la valeur marketing.
Bird ajoute la paire d'en-têtes de désabonnement aux messages marketing et l'inclut dans le contenu signé. Son endpoint hébergé enregistre l'opt-out. Les envois marketing suivants respectent cette suppression, l'enregistrement qui empêche la livraison vers une adresse ayant opté pour le retrait.
Pour les envois individuels HTTP API, laissez les deux en-têtes de désabonnement marketing à Bird. Fournir l'un ou l'autre en-tête géré retourne 422. Quand vous envoyez à une audience avec les broadcasts de Bird, Bird ignore les en-têtes de désabonnement marketing que vous fournissez. Les soumissions SMTP ignorent aussi ces en-têtes.
Bird n'ajoute pas automatiquement la paire gérée aux messages transactionnels. Les envois individuels HTTP API peuvent transmettre des en-têtes de désabonnement personnalisés sur cette catégorie.
Le guide des liens de désabonnement explique le lien visible dans le corps du message et le pied de page par défaut. Catégories explique comment la classification affecte la livraison aux destinataires ayant opté pour le retrait.
En bref
RFC 8058 utilise une paire d'en-têtes.
List-Unsubscribe fournit la destination HTTPS, et List-Unsubscribe-Post identifie la requête de désabonnement en un clic.
La signature doit couvrir les deux en-têtes.
Une signature DKIM valide doit inclure les deux en-têtes de désabonnement dans sa liste signée.
L'endpoint ne nécessite ni connexion ni redirection.
La requête transporte ses informations d'identification dans l'URL et doit fonctionner sans cookies ni autorisation.
Les liens visibles et le traitement dans les délais restent importants.
Les exigences des fournisseurs incluent un lien de désabonnement dans le corps du message et un traitement sous deux jours.