Catégories
Tips

Emails : ne soyez pas considérés comme un spam

Un des problèmes avec la gestion des mails maison, c’est qu’on a vite fait d’être considéré comme un spam par un filtre un peu trop difficile. Très gênant si vous pensiez gérer votre adresse professionnelle. Heureusement il existe des solutions. J’ai mis à jour la page de mon wiki concernant la gestion des mails avec reverse DNS, SPF et DKIM. Voici un résumé :

Les filtres

Le principe des filtres anti-spam (dont SpamAssassin est le plus connu) est très simple. Vous partez d’un score de zéro. Lorsque le filtre détecte quelque chose de suspect votre score augmente, lorsque vous avez un comportement que n’aurait pas un spammeur, vous perdez des points. Arrivé à une certaine limite, vous devenez un spam.

Évidement toute la difficulté réside à bien pondérer et trouver les bons critères. Le fait d’utiliser des mots comme « viagra » va vous faire gagner des points. Les spammeurs l’ayant comprit, ils utiliseront v1agra par exemple. Les critères faisant perdre des points ne doivent pas non plus être simples sinon un spammeur les utilisera pour passer inaperçu.

Il existe également le filtre bayésien plus complexe mais très puissant qui va utiliser des probabilités statistiques. Ce filtre se base sur le contenu du message et l’on a donc pas d’influence coté serveur. Évitez juste de parler de vente de médicaments en ligne dans vos messages.

Voici deux exemples de scores (spamassassin et un inconnu) plutôt mauvais que j’ai eu sans rien activer :

X-SGSI-SpamCheck: n'est pas un polluriel, SpamAssassin (score=1.982,requis 5,
 BAYES_50 1.00, RDNS_DYNAMIC 0.98, SPF_HELO_PASS -0.00)

Il s’agit du filtre de mon université, il considère que l’on est un spam à partir de 5 et m’a mit 1.982, rien de dramatique.

X-Spam-Flag: YES
X-Spam-Score: 6.782
X-Spam-Level: ******
X-Spam-Status: Yes, score=6.782 tagged_above=4 required=6.3
	tests=[BAYES_50=0.8, EIGHTBIT_ENCODING=1, RCVD_FAKED_HELO=2,
	RCVD_SHORT_HELO=2, RDNS_DYNAMIC=0.982] autolearn=no

Il s’agit ici d’un filtre d’entreprise qui est beaucoup plus sévère. Il m’a mit un score de 6.782 alors que sa tolérance est à 6.3. Cela a eu pour effet de mettre un gros ***SPAM*** dans le sujet du message.

« Capitaine, je crois que notre filtre SpamAssassin est un peu trop permissif… »

Reverse DNS

La résolution DNS classique est de faire correspondre une URL à une IP. Le reverse DNS est le chemin inverse. Par défaut, j’ai, dans le cas de mon serveur OVH, 178-33-111-174.kimsufi.com pour l’IP 178.33.111.174. C’est ça qui explique mon « bonus » RDNS_DYNAMIC 0.98.

En mettant votre nom de domaine à la place, le problème est réglé. Vous pouvez vérifier que vous avez la bonne valeur via la commande $ dig -x 11.22.33.44 dans le champ PTR. J’ai remarqué que certains serveurs prenaient beaucoup de temps à mettre à jour leurs reverse DNS donc prenez votre mal en patience.

Si vous possédez comme moi plusieurs domaines pointant sur la même IP, sachez qu’il est inutile de mettre plusieurs entrées DNS PTR, cela pourrait être même contre productif. [Source]

SPF

Le plus simple. SPF pour Sender Policy Framework est simplement une entrée DNS depuis quel domaine on peut envoyer un email. Dans le cas d’un seul domaine qui n’envoie que depuis ses entrées MX, l’entrée DNS est

mart-e.be    SPF    v=spf1 mx ~all

Vous pouvez ainsi spécifier d’autres serveurs (si par exemple vous utilisez le relais SMTP de votre FAI). Pour les cas plus complexes, je vous renvoie vers le site officiel.

La valeur ajoutée par cette règle est assez faible. J’ai eu droit à SPF_HELO_PASS -0.00 pour le premier serveur mail et SPF_HELO_PASS=-0.001,SPF_PASS=-0.001 pour le deuxième. Vous pouvez vous dire que l’intérêt est donc limité mais voyez plutôt comme ceci : si un jour quelqu’un essaye d’envoyer du spam en se faisant passer pour vous, la vérification SPF échouera et son score de spam augmentera de façon non-négligeable.

Attention: SPF casse la redirection. Si vous envoyez un mail à machin@gmail.com sur laquelle votre correspondant a réglé une redirection automatique vers machin@myopera.com, c’est l’adresse IP de Google qui apparaîtra et pas la votre. La vérification SPF échouera donc. Cependant, ce n’est pas si grave que ça parce que le filtre anti-spam de Opera doit avoir l’habitude de recevoir tous les emails venant de machin@gmail.com qui a des bonnes chances d’être dans une liste blanche. Donc si le serveur du correspondant est bien fait, ça ne devrait pas poser de problèmes.

DKIM

Plus difficile, il s’agit ici de signer les headers du mail envoyé. La clef publique est spécifiée dans les DNS. J’ai choisi d’utiliser OpenDKIM. On génère des clefs asymétriques pour chaque domaine et on publie la clef publique dans les DNS. Celle pour ce domaine est par exemple :

default._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQChUywElHkvIJwgp9BYce97yhv0ImwK5+2Jm0CHBCfjYpeV7pSaAh/aYmX9+BJcSupVnJYBPf4DT/AFbV7O6snG6rGf3bnJSHdfyGa7Zq8a/7ERdTYo6/W5LJvaenDAxqlWPlgVafQtncRt+4/iF133FXLpC4VL6NmbMirK0yMRKQIDAQAB"

Lorsque que vous signerez un email, on aura par exemple.

DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mart-e.be; s=default;
t=1353269228; bh=frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=;
h=Date:From:To:Subject:From;
b=VQUjpDqQbD4OH4dRO5Ex3J0Qxoa5aKv6m7EYnxUgXE+SJd45PzJ0ZhIMzlIah3PRJ
6UQX7rZizYU7gp6PioYFovADAW0o31iZYyTpuiUlEXpKAFeoRl0gR7wTNZrPdkSgSr
A8bxxBjJPIUPpYW6ePuRixrumcCiNu2a0o8IC4Bk=

Votre correspondant supportant DKIM vérifiera la signature. Si elle est valide, vous perdez des points à votre score spam, si elle est invalide, vous en gagnez. Ben oui il ne suffit pas dire qu’on fait du DKIM pour ne pas être un spam, il faut encore bien le faire.

Conclusion

En appliquant ces trois méthodes, je suis passé à un score négatif sur le premier serveur et inférieur à 4 sur le deuxième (score à partir duquel il n’indique plus le détail).

Cela ne vous fera pas passer à travers les filtres les plus drastiques mais devrait diminuer le risque. N’hésitez pas à faire des tests sur plusieurs serveurs différents. Les filtres de Google et Yahoo ne donnent pas le détail du score mais les entreprises privées ou gens qui ont installé des filtres maisons sont plus sympa.

Si vous connaissez d’autres moyen de diminuer ce score, n’hésitez pas à partager. Je n’ai pas exemple pas d’explication sur le RCVD_FAKED_HELO et RCVD_SHORT_HELO qui m’ont donné chacun deux points ou le EIGHTBIT_ENCODING que je n’explique pas non plus (tu aurais préféré quoi ?) dans l’exemple ci-dessus.

9 réponses sur « Emails : ne soyez pas considérés comme un spam »

Pour RCVD_FAKED_HELO et RCVD_SHORT_HELO, il n’y a effectivement pas de doc sur le net. Mais je pense savoir d’où cela vient.

Dans le protocole SMTP, tu es sensé commencer par un HELO, suivit du FQDN de ta machine. De mémoire, c’est /etc/mailname qui le définit.
Dans ton cas, tu ne dois pas envoyer un FQDN mais uniquement le nom court de ta machine (foo au lieu de foo.example.org), d’où le RCVD_SHORT_HELO.

Le RCVD_FAKED_HELO doit être un corollaire du RCVD_SHORT_HELO, puisque la machine réceptrice ne doit pas être capable d’en déterminer le reverse vu qu’elle ne résoud pas par défaut sur le même domaine (paramètre search dans /etc/resolv.conf).

Tu parles du résultat de « hostname –long » ? En fait dans mon /etc/mailname j’avais mit mon nom de domaine ce qui explique sans doute l’erreur.
Merci

Oui, le FQDN est retourné par « hostname –long ».
Pour le configurer, c’est dans /etc/hosts, c’est la 1ère valeur de 127.0.0.1 qui n’est pas « localhost ».

Un bon fichier /etc/hosts est donc sous la forme

127.0.0.1 localhost.localdomain localhost
127.0.0.1 machine.example.org machine

avec comme fichier /etc/hostname

machine

D’accord je vois.
Par contre dans /etc/hosts la deuxième ligne est avec mon adresse IP publique, pas 127.0.0.1 (auto-générée par Proxomox je pense).

@nicolas : les 3 critères sur lesquels je m’interrogeais n’apparaissent pas dans la liste, d’où mon hypothèse que le serveur n’utilisait pas spamassassin.

Cependant on a des règles RCVD_FAKE_HELO_DOTCOM et BODY_8BITS qui pourraient être équivalentes (et je comprend toujours pas le problème d’avoir un encodage en 8 bits).

Bonjour,
Les grands fournisseurs d’adresses emails gratuits tels que Google et Yahoo portent de plus en plus d’importance aux retours effectués par leurs utilisateurs (si plusieurs clients considèrent un email comme un spam notamment) , mais également au nombre d’email envoyés par un serveur à destination d’adresses emails invalides (boites aux lettres inexistantes).

Il est donc primordial de s’assurer avant l’envoi d’un emailing, même petit, que sa base de correspondant est saine. Il existe pour cela des services sur Internet comme http://www.mygoodbase.com/ pour nettoyer en quelques minutes votre base d’adresse avant d’envoyer vos emails.

Cdlt, Tania

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *