Cela fait maintenant plus de 15 ans que j’administre mon serveur de courriels en utilisant Postfix (réception et envoi) et Dovecot (pour s’interfacer avec IMAP et permettre aux clients courriels comme Thunderbird de se connecter).

En 15 ans, çà n’a pas toujours été un long fleuve tranquille comme cet article va l’expliquer; comparativement à d’autres services que j’héberge sur mon serveur dédié (dns, web, mysql, et pendant un moment j’ai même hébergé un serveur SVN et un serveur Jenkins !), les courriels sont dans une classe à part en terme de … difficulté de résolution des problèmes !

Lutter contre le spam sur son serveur dédié

Je suis loin d’être un expert (j’ai quand même documenté sur ce blog mes étapes pour configurer un serveur Ubuntu en serveur de courriels), en vrai je n’utilise même pas d’antispam; fut un temps j’utilisais SpamAssassin, mais autant que je me souvienne, je n’ai pas été convaincu par l’utilité ni la fiabilité; bref je me suis rapidement tourné vers Postgrey, un logiciel compagnon de Postfix qui demande au serveur expéditeur de renvoyer le courriel dans un délai configurable (10mn par exemple) – généralement les (robots) spammeurs n’obéissent pas à cette règle, ainsi çà filtre assez bien les courriels indésirables.

Le problème avec Postgrey ? et bien on ne reçoit pas les courriels instantanément car il faut attendre que le serveur expéditeur renvoie le courriel. Pas pratique lorsqu’on reçoit par courriel un code à usage unique qui a une validité de quelques minutes…

La solution est alors de gérer une liste blanche de serveurs expéditeurs à qui on fera confiance et à qui on ne demandera pas de renvoyer le courriel. Par exemple:

Pour le peu d’utilisateurs que j’ai çà fonctionne plutôt bien…

En fait, le plus gros problème que rencontrera un administrateur de serveur de courriels, ce sera de faire en sorte que les courriels des utilisateurs ne soient pas filtrés par les solutions courriels (gmail, outlook, yahoo) des destinataires !

Livrer avec succès tous les courriels émis par son serveur de courriels auto hébergé

Les années 2010 ont vu apparaître une foule de règles et standard pour lutter contre le spam; la première chose à faire lors que l’on configure son serveur de courriels, c’est de montrer qu’on est un acteur de confiance en implémentant toutes ces règles.

Les règles de base pour avoir un serveur de courriels réputé fiable

• Adresse IP du serveur de courriel non associée à un ancien spammeur; il existe des services en ligne pour faire cette vérification, c’est important de la faire lors de l’achat du serveur dédié
• SPF: lister au niveau de l’enregistrement DNS quels sont les serveurs de courriels autorisés à envoyer des courriels pour le nom de domaine; exemple: je déclare que serveur.dahanne.net est un serveur de courriel connu pour envoyer les courriels en @dahanne.net.
• DKIM: encore un enregistrement DNS qui permettra aux destinataires de vérifier que l’envoyeur du courriel a utilisé une signature connue
• DMARC: un autre enregistrement DNS pour spécifier qui prévenir en cas de courriel reçu qui ne correspond pas aux règles SPF /DKIM

Malheureusement, même après avoir implanté ces techniques pour montrer patte blanche, il se peut que certains fournisseurs de courriels ne vous fassent pas confiance.

Que faire quand les courriels envoyés n’arrivent jamais dans les boîtes de réception hotmail, outlook, live.com …

La première chose est de contacter le fournisseur de courriels qui ne livre pas; par exemple Microsoft ou Google ou Yahoo (à eux 3 ils représenteraient 70 à 90% des boites courriels en utilisation) ils ont chacun une procédure de mitigation où l’ont peut demander pourquoi ils choisissent de refuser nos courriels, ou les classer comme spam ou pire encore les ignorer totalement (> /dev/null ?!)

De mon expérience, c’est frustrant (personne ne répond) et inutile (rien ne change); après tout pourquoi ils mettraient de l’effort à investiguer des problèmes avec un tout petit envoyeur ?

J’ai dû à contre cœur me résoudre à utiliser un relai connu et réputé pour faire transiter mes courriels vers certains fournisseurs de boîtes courriel.

Utiliser un relai de courriel pour certains destinataires

Après plusieurs tentatives infructueuses à plaider ma cause chez des géants du courriel, et après m’être lassé de demander à certains destinataires de regarder leur dossier de spam à chaque envoi de courriel (…) j’ai eu la chance de découvrir cet excellent article de NerdQuickies qui détaille comment utiliser un relai courriel.

Cet article décrit en quelques étapes comment mettre un relai en place dans Postfix, et comment choisir uniquement certains fournisseurs pour lesquels on utilisera le relai (parce qu’on a pas encore renoncé totalement à envoyer les courriels sans intermédiaire !)

• création d’un compte gratuit mailjet: pas besoin d’ajouter de carte de crédit au compte et le compte gratuit permet l’envoi de 200 courriels / jour, ou encore 6000 courriels / mois
• configuration SPF et DKIM de mailjet comme distributeur de courrier sur le domaine.

Cette étape était la plus subtile: il fallait ajouter et / ou mettre à jour des entrées DNS de type TXT… Subtile car il faut attendre la propagation des DNS, faire bien attention à tout mettre sur 1 ligne, etc.

Avec Bind9, j’ai obtenu à la fin ces modifications dans mes entrées DNS: (valeurs offusquées)

• configuration du relai dans postfix

Comme décrit dans l’article original, juste 3 fichiers à modifier, soit:

Le moment du test tant attendu ? s’envoyer un courriel sur 1 boite microsoft (outlook.com par exemple) et vérifier qu’il n’arrive pas dans les spams !

On prêtera attention aux logs de postfix:

Et aux entêtes du courriel reçues sur outlook.com:

Conclusion: la panacée ?

Et bien, pas vraiment…

Le but de l’auto hébergement c’est s’amuser à jouer aux admins système du dimanche, certes, mais aussi c’est démontrer qu’internet ce n’est pas juste le terrain de jeux de quelques géants, que çà reste accessible à tout monde d’y exposer ses services.

Mon plus grand regret c’est qu’il est impossible ou presque de se passer d’un prestataire « reconnu » de courriels (comme mailjet mais on aurait pu utiliser sendgrid, AWS SES, etc.) pour pouvoir passer à travers les filtrages anti spams de géants qui semblent finalement bénéficier de cette situation… (ce n’est pas tout le monde qui a la patience de débugger des courriels non livrées; c’est plus rapide de créer un compte gmail…)

Est ce qu’un jour je serai obligé d’utiliser CloudFlare ou CloudFront pour exposer mon serveur HTTP au public ?

Admins système du dimanche, courage, on n’a pas dit notre dernier mot !