J’ai reçu une notification d’AWS indiquant que Yahoo et Gmail mettent en œuvre une longue liste de nouvelles règles pour les expéditeurs d’e-mails « en volume ».
Discourse, je pense, peut entrer dans cette catégorie, surtout si vous utilisez le mode liste de diffusion (comme nous le faisons).
Y a-t-il des plans (ou peut-être le fait-il déjà) pour mettre en œuvre ces nouvelles exigences dans les e-mails Discourse ?
Les changements / exigences sont décrits ici :
Certains d’entre eux sont externes comme DKIM et SPF, mais il y a aussi des changements requis dans le corps de l’e-mail.
Les expéditeurs en volume doivent inclure un mécanisme de désinscription en ajoutant un lien facile à trouver dans le message. Les règles des fournisseurs de boîtes aux lettres de février 2024 obligeront les expéditeurs à ajouter en plus des en-têtes de désinscription en un clic tels que définis par RFC 2369 et RFC 8058. Ces en-têtes facilitent la désinscription des destinataires, ce qui réduit le taux de plaintes des destinataires marquant les messages comme spam.
De nombreux facteurs peuvent entraîner la classification de vos messages comme en volume par n’importe quel fournisseur de boîtes aux lettres. Un volume supérieur à 5000 par jour est un facteur, mais le facteur principal utilisé par les fournisseurs de boîtes aux lettres est de savoir si le destinataire souhaite réellement recevoir le courrier.
Discourse génère déjà des liens de désabonnement dans l’en-tête List-Unsubscribe et dans le corps du message. Les avez-vous examinés et les avez-vous trouvés insuffisants ?
Cela a de nouveau attiré mon attention récemment, et j’ai eu la bande passante nécessaire pour approfondir les détails.
Nous avons un en-tête List-Unsubscribe depuis longtemps, mais il y a une forte poussée pour avoir un véritable désabonnement en un clic sans étape de confirmation supplémentaire de la part de l’expéditeur.
J’ai eu un problème similaire sur une autre liste de diffusion. Le problème avec la désinscription en un clic est que de nombreux clients de messagerie et filtres anti-spam/antivirus cliquent/activent des liens pour les “enquêter”, ce qui finit par désabonner quelqu’un. Vous avez donc absolument besoin d’une confirmation d’une sorte, pas seulement d’une activation de lien.
Nous avons eu un tas de personnes, en particulier celles utilisant Enterprise/Outlook, qui ont été automatiquement désabonnées.
Mais peut-être que si cela se fait via cet en-tête, c’est bon.
Cette préoccupation est spécifiquement abordée par cette RFC.
Une requête GET ne doit pas déclencher le désabonnement pour cette raison exacte, seulement un POST qui doit être explicitement confirmé par l’utilisateur.
Lorsque j’ai testé cela dans Gmail, il y a une confirmation secondaire, mais elle se produit à partir du client de messagerie — je pense donc que cela répond toujours aux exigences de « désabonnement facile » sans risquer de désabonnements involontaires dus aux investigations du client de messagerie :
