Faux positifs : les dégats collatéraux des mails légitimes

Retrouvez cet article sur la nouvelle version du Blog Snipemail :
Faux positifs : les dégats collatéraux des mails légitimes

Comments

[Rédigé par : Grégory]

Bonjour,

Je complèterais tes remarques par le fait que, d'après ce que j'ai pu constater, lors de l'analyse du contenu d'un message, de nombreux autres critères peuvent faire basculer l'email en boîte spam: non-respect des standards des formats d'email, code HTML de mauvaise qualité (par exemple, si le code est créé par Word ou Publisher), noms de domaine différents pour chaque lien du message, lien commençant par http://192.1.., etc.

Concernant les adresses IP, tu parles du fait qu'il est possible d'être blacklisté lors de l'utilisation d'un hébergement mutualisé. Je me demande donc si ce risque n'est pas aussi important lorsqu'on utilise une solution d'emailing en ASP ?

Sinon, si on utilise un serveur SMTP interne pour l'envoi des campagnes, il faut veiller à ce que le DNS soit correctement configuré (surtout pour AOL).

Et merci pour ces articles toujours très intéressants. Ils participent grandement à l'éducation de chacun d'entre nous pour une utilisation respectueuse de l'e-mail.

[Rédigé par : Charles Boone]

Merci Gregory pour tes commentaires.
Il y a malheureusement pleins d'éléments qui peuvent faire qu'un email aboutit en spam. Je suis resté sur l'IP parce qu'elle est souvent la cause d'un tel classement. Le code html pas propre à la rigueur quand Outlook est mal configuré et utilise Word en tant qu'éditeur de l'email.
Par contre pour les liens avec différents noms de domaines ou ceux qui cachent leur destination finale, ou les liens en ip directe, ils sont rarement utilisés par un utilisateur normal :-) Ce sont le plus souvent des vrais spams et pas des faux positifs.

L'utilisation des serveurs SMTP interne est de plus en plus rejetée car les serveurs de mails et les filtres anti-spams vérifient le reverse de l'IP et elle n'est pas correctement résolue avec un serveur interne.

Enfin pour ton interrogation sur les solutions emailing en ASP, cela va dépendre de la solution. Certaines se contentent de n'être qu'un serveur de mail distant avec un programme posé dessus. D'autres font un travail constant avec les hébergeurs, FAI et webmail pour lever toutes les alertes de spam et dont rester des adresses blanches. D'autres encore vous fournissent une IP propre au début, à vous de vous débrouiller avec. Je reçois au moins une fois par semaine des emails en provenance de sources censées être propres mais comme les utilisateurs envoient à tort et à travers, l'ip propre est maintenant identifiée comme spam systématiquement. Pourtant ce type d'outil oblige par contrat de n'utiliser que des bases propres (d'où encore une fois le conflit entre la LEN et l'opt-in réel cad le psychologique)
Cela fera sans doute l'objet d'un nouvel article ;-)