Je voudrais fournir un simple clic sur les liens "Se désinscrire" dans le pied de page des e-mails envoyés par mon service.
De toute évidence, de nombreux scanners de spam analyseront les e-mails et suivront tous les liens trouvés dans les e-mails pour analyser leur contenu à la recherche de logiciels malveillants. Une solution de contournement que j'ai utilisée jusqu'à présent:
- Si la page "Se désinscrire" est demandée via HTTP GET, elle affiche un simple formulaire de confirmation et un peu de JS qui soumet le formulaire au chargement de la page
- Si la page "Désinscription" est demandée via HTTP POST, nous désinscrivons l'utilisateur
De cette façon, l'utilisateur n'aura généralement besoin que d'un seul clic sur le formulaire et recevra un message "Vous avez été désabonné". S'ils ont désactivé JS, ils peuvent toujours soumettre manuellement le formulaire de confirmation.
Maintenant, le problème est que certains scanners comme l'ATP d'Office365 ouvriront les pages et exécuteront JS à l'intérieur . En exécutant JS, ils soumettent le formulaire et entraînent la désinscription automatique de l'utilisateur.
J'ai envisagé d'ajouter des vérifications à la logique JS de soumission automatique:
- ne pas soumettre automatiquement pour des agents utilisateurs spécifiques
- ne pas soumettre automatiquement pour des plages d'adresses IP client spécifiques
- déclencher l'événement de soumission automatique lors du déplacement de la souris
Mais tout cela semble être des méthodes fragiles, des hacks au mieux, qui ne manqueront pas de briser lorsque les scanners de messagerie changeront de tactique.
Je suis sûr que ce problème a mordu beaucoup de gens avant moi. Existe-t-il des solutions de contournement raisonnables, en plus de simplement abandonner la fonctionnalité de simple clic?
PS. J'ai ajouté la prise en charge de RFC 8058, mais les utilisateurs vont toujours cliquer sur les liens dans le pied de page.
la source
Réponses:
Il s'agit d'un sujet de débat en cours au M³AAWG (Groupe de travail sur la messagerie, les logiciels malveillants et la lutte contre les abus mobiles). C'est un gâchis et il n'y a pas de solutions faciles. On dirait que vous faites tout correctement, mais certains systèmes anti-spam sont un peu trop agressifs.
Le gros problème est que tout ce que vous pouvez faire peut également être fait par un responsable marketing ou un spammeur abusif.
La meilleure proposition que j'ai entendue est simplement de mettre un chronomètre sur l'action. Ajoutez un captcha pour les utilisateurs qui se désabonnent dans les 5 minutes suivant la livraison et supprimez le captcha par la suite. (N'implémentez pas cela pour votre lien RFC 8058 List-Unsubscribe-Post.)
Ma prochaine proposition préférée est d'ajouter un lien canari au message. Cela devrait être invisible pour les lecteurs humains. S'il est suivi, il annule l'activité de clic récente de cette IP et interdit l'IP des déclencheurs d'action pendant un certain temps.
J'aime aussi vos idées, assurez-vous simplement que si Javascript est désactivé, l'utilisateur peut toujours se désinscrire après un clic sur le bouton de confirmation.
Il y a une partie de moi (attention, je suis un chercheur anti-spam) qui veut ces faux positifs. J'espère que cela apprendra à mes pairs qu'ils font un si mauvais travail et que ces escalades continueront de leur arriver. De votre point de vue, vous obtenez de passer la balle (même si vous perdrez quelques abonnés dans le processus).
Les systèmes de détection de spam doivent être prudents pour éviter les liens de gestion des abonnements (au moins jusqu'à ce que les méchants commencent à déguiser leurs charges utiles en liens de désinscription).
la source