Ça fait quelques temps que je vois sur les internets des gens qui jettent l’éponge après s’être lancé dans l’aventure de hébergement de leur mails.
La raison : devoir sans cesse se justifier auprès – entres autres – des GAFAM. Car malheureusement la présomption d’innocence n’existe pas dans ce milieu. Vous serez jugé (ou au mieux présumé) coupable de spam et ce jusqu’à preuves du contraire. Votre mail, s’il n’essuie pas un refus catégorique de prise en charge de la part du serveur, atterrira donc dans le dossier Spam de votre destinataire. Bon courage pour être lu…
Pourtant, de simples précautions suffises pour que ça se passe relativement bien (bon sauf pour Microsoft qui a juste décidé d’être con…). Passons-les en revue.
État des lieux
Avant d’entreprendre toute action, la première chose à faire est de faire l’état des lieux de votre archi de courrier sortant. Pour cela, il y a plusieurs services en ligne :
- http://www.allaboutspam.com/
- http://dkimvalidator.com/
- Return Path (checkmyauth@auth.returnpath.net)
Le principe, vous envoyez un mail – comme à votre habitude – à une adresse bien connue et on vous dit comment vous êtes perçu. (Juste niveau spam hein, pour le look faut voir ailleurs).
Bon, je vous avoue j’ai mon petit préféré. Leur batterie de test est plutôt complète et ils vont même jusqu’à donner l’URL des résultats via un bounce. Cela permettra aussi de valider la configuration de votre serveur mail et que ceux-ci arrivent bien dans votre boite mail.
Normalement si votre serveur mail se fait envoyer bouler définitivement par un autre, celui-ci devrait, tout vexé qu’il est, vous générer un rapport de non délivrance et le fourrer dans votre Inbox. Chose plutôt utile, car au moins vous serez au courant qu’un mail envoyé n’a jamais atteint sa destination finale.
Testons
Première chose à faire, donc, envoyer un mail à l’adresse indiquée et attendre patiemment. En effet, la première chose testée est le respect de leur politique de greylisting :
2017-02-02T14:11:57+01:00 thyburce postfix/smtp[22445]: 9B0A6C01E7: to=<test@allaboutspam.com>, relay=mx.allaboutspam.com[96.126.107.60]:25, delay=5.9, delays=0.02/0.01/0.3/5.5, dsn=4.0.0, status=deferred (host mx.allaboutspam.com[96.126.107.60] said: 452 Greylisted. Please try again after some time. (in reply to end of DATA command))
Il faut donc que votre serveur attende quelques minutes avant de retenter un nouvel envoi de mail.
Quelques minutes plus tard…
2017-02-02T14:18:26+01:00 thyburce postfix/smtp[23008]: 9B0A6C01E7: to=<test@allaboutspam.com>, relay=mx.allaboutspam.com[96.126.107.60]:25, delay=395, delays=389/0.01/0.32/5.6, dsn=5.0.0, status=bounced (host mx.allaboutspam.com[96.126.107.60] said: 552-Thanks for using ALLABOUTSPAM.COM Email server test. Your test results are 552 available at http://www.allaboutspam.com/email-server-test-report/?key=D979EE770E39318B6D5A9AC11561364E (in reply to end of DATA command))
Le mail part et… se fait envoyer bouler du serveur. Tout est nominal ! C’est le comportement voulu, le message d’erreur comporte un lien avec le résultat de l’analyse de votre système de courrier sortant. Théoriquement vous devriez avoir un rapport de « bounce » dans votre boite mail.
Allons voir le détail de ce rapport…
Le Reverse DNS
Premier truc, le serveur distant va la plupart du temps faire une résolution d’adresse inverse (IP > Nom). Vous devez avoir une résolution inverse fonctionnelle !
Le HELO
Et non il ne manque pas un L :)
C’est la première chose à dire lorsqu’on se présente en SMTP à un autre serveur. Faut dire bonjour. Et quant à faire, autant se présenter correctement.
Ici votre serveur devrait se présenter selon un nom de domaine résolvable et si possible correspondant au domaine obtenu plus haut par résolution inverse. Là c’est la classe, vous marquez des points (non vraiment pour de vrai).
Les Blacklist
Il existe tout un tas de blacklist disponible gratuitement, privées ou sur abonnement. Ici tout dépend de ce que vous avez en face. Le mieux c’est de vérifier aussi par vous-même. N’oubliez pas de tester les domaines portés par votre serveur mail ainsi que vos IP de sortie !
La plupart du temps il n’y a pas de raison que votre domaine soit blacklisté à moins d’avoir :
- envoyé une quantité de spam auparavant,
- repris un ancien domaine déjà blacklisté pour la raison précédente,
- un domaine contenant des mots explicites.
Pour l’IP c’est un peu plus fourbe… Si vous êtes derrière de l’ADSL, n’y pensez même pas vous êtes blacklisté et il n’y aura rien à faire. Ça ne vous empêchera pas d’envoyer des mails (si votre FAI le permet).
Il peut aussi arriver qu’un ou plusieurs voisins de votre plage d’IP envoient du spam et certains éditeurs de blacklist décident de bannir en totalité la plage d’IP associée.
La plupart des éditeurs possèdent un formulaire de contact afin de demander d’être retiré de leur liste. De mon côté, j’ai toujours eu un retour positif de leur part (après avoir montré patte blanche bien sûr).
Une fois votre courrier sortant bien configuré, c’est la seule partie qui rester à surveiller de temps en temps et qui vous demandera parfois un peu de fil à retordre. Rien de bien méchant cependant c’est juste un peu d’administratif :)
Le SPF & DKIM
Ça on ne les présente plus… Ils sont obligatoires (vraiment). Le SPF c’est un record à publier dans son DNS, ça ne coûte rien à faire et il y a des tutos partout sur le net pour le mettre en place.
Le DKIM c’est un poil plus compliqué, un record DNS + conf de votre serveur mail pour signer tous les mails sortant. Encore une fois : un petit tuto et on n’en parle plus. Une fois que c’est en place ça j-u-s-t-e marche.
Inutile de préciser que le test doit être positif.
URIBL (Realtime URI Blacklist)
Ça c’est plus vicieux. J’imagine que vous n’allez pas envoyer des liens à vos proches pour une augmentation de taille de chibre ! Par contre, certains Header SMTP peuvent faire tiquer l’antispam qui pourrait considérer le mail comme du Spam (déjà qu’il est sur la défensive…).
De mon côté, j’ai mis en place une politique de nettoyage des headers des mails sortant pour éviter toutes fuites d’info non souhaitées et éviter que l’antispam distant me fasse un caca nerveux !
Petite contrainte avec le DKIM cependant : postfix doit nettoyer les headers avant la transmission au processus de signature DKIM. En effet, la signature DKIM se base sur tout le contenu du mail. Si vous altérez le contenu (suppression des headers) après la signature, celle-ci ne sera plus valide.
Idem pour le courrier entrant, le plus simple étant de ne pas y toucher.
Il faut donc appliquer notre politique de nettoyage qu’aux courriers sortant uniquement.
Bonne nouvelle postfix sait faire ça. Rendez-vous dans le fichier master.cf et localiser la ligne submission (qui correspond au service SMTP des courriers sortant) :
On va lui rajouter un petit service de « cleanup » :
submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o cleanup_service_name=subcleanup -o content_filter=smtp-amavis:[127.0.0.1]:10026
Chez moi c’est Amavis qui s’occupe de la signature DKIM c’est donc le dernier service appeler avant l’envoi effectif du mail.
Tout en bas du fichier rajouter les lignes suivantes :
subcleanup unix n - - - 0 cleanup -o header_checks=pcre:/etc/postfix/headers_cleanup.pcre
On demande donc au service d’aller faire le ménache dans les headers.
Mais PoGo que contient ce fichier headers_cleanup.pcre ?
/^Received:/ IGNORE /^X-Originating-IP:/ IGNORE /^X-Mailer:/ IGNORE /^Mime-Version:/ IGNORE /^Message-Id:/ IGNORE
Les header Received révèlent tout le parcours du mail avant d’arriver à votre serveur de mail sortant. Ils indiquent notamment IP/Nom de domaines internes par lesquels le courrier aura transité avant d’être jeté dans les Internet. C’est justement ça qui peut titiller certains antispam à cheval sur les règles (note pour plus tard, insérer ici un jeu de mot selon l’inspiration du moment…).
X-Originating-IP, s’il est supporté par votre client mail (ou webmail) peut révéler votre IP publique utilisée par votre client lors de l’envoi de votre mail.
Le nettoyage des autres headers permettent d’éviter la divulgation d’information non pertinentes.
En conclusion
Faites en sorte d’avoir le rapport le plus clean possible car une fois tous ces points vérifiés, tout devrait bien se passer.
N’hésitez pas à relancer le test tous les 2/3 mois.