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 !
Contents
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:
|
1 2 3 4 5 6 7 8 9 10 |
cat /etc/postgrey/whitelist_clients #Anthony added mandrillapp.com firefox.com amazonses.com microsoftonline.com twitter.com ovh.net okta.com # etc. |
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.netest 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)
|
1 2 3 4 5 |
vim /etc/bind/mondomaine.hosts dahanne.net IN TXT "v=spf1 include:spf.mailjet.com a mx ip4:192.95.25.170 ~all" mailjet._43434343 IN TXT aaaaeeee mailjet._domainkey.dahanne.net. IN TXT "k=rsa; p=xxxxMMMM4343" |
- configuration du relai dans postfix
Comme décrit dans l’article original, juste 3 fichiers à modifier, soit:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
# vim /etc/postfix/main.cf [...] #Mailjet relay smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl/sasl_passwd transport_maps = hash:/etc/postfix/transport [...] # postmap /etc/postfix/main.cf # vim /etc/postfix/transport hotmail.com smtp:[in-v3.mailjet.com] hotmail.co.uk smtp:[in-v3.mailjet.com] hotmail.fr smtp:[in-v3.mailjet.com] hotmail.de smtp:[in-v3.mailjet.com] outlook.com smtp:[in-v3.mailjet.com] outlook.de smtp:[in-v3.mailjet.com] outlook.fr smtp:[in-v3.mailjet.com] outlook.be smtp:[in-v3.mailjet.com] outlook.in smtp:[in-v3.mailjet.com] live.com smtp:[in-v3.mailjet.com] # postmap /etc/postfix/transport # vim /etc/postfix/sasl/sasl_passwd in-v3.mailjet.com MAILJET_SMTP_ACCESS_KEY: MAILJET_SMTP_SECRET_KEY # postmap /etc/postfix/sasl/sasl_passwd # /etc/init.d/postfix reload |
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:
|
1 2 3 4 5 6 |
# tail -f /var/log/mail.log Sep 30 23:39:36 localhost postfix/qmgr[24993]: 7425DFF14B: from=<moi@domaine.com>, size=822, nrcpt=1 (queue active) [...] Sep 30 23:39:38 localhost postfix/smtp[6303]: 7425DFF14B: to=<moi@outlook.com>, relay=<strong>in-v3.mailjet.com</strong>[104.199.96.85]:25, delay=2, delays=0.22/0.03/1.6/0.22, dsn=2.0.0, status=sent (250 OK queued as xxx) Sep 30 23:39:38 localhost postfix/qmgr[24993]: 7425DFF14B: removed [...] |
Et aux entêtes du courriel reçues sur outlook.com:
|
1 |
Received: from o137.p8.mailjet.com (87.253.233.137) by BN8NAM11FT015.mail.protection.outlook.com (10.13.176.90) with Microsoft SMTP Server |
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 !
Bonjour,
Merci pour ton article !
Si je peux me permettre voici comment j’ai construit ma solution :
Pour mon hébergement de mail j’utilise :
Un vps à 4€ chez pulse héberge qui me permet d’avoir une ip fixe utilisé pour le reverse dns, dkim, spf, dmac où j’y ai installé proxmox mail gateway qui communique à travers un vpn wireguard vers mon serveur de mail (ispconfig juste pour la partie email) dans mon réseau local. Ainsi je ne passe plus par un relais comme orange. j’ai maintenant moins de maintenance dessus et une bonne délivrance de mes mails. Voilà tout @+
@Pascal: ok mais tu as quand meme la « chance » d’avoir un VPS qui est capable d’envoyer avec succès vers yahoo, gmail, microsoft ? dans mon cas, mon serveur dédié est hébergé chez OVH à Beauharnois au Canada et il a une IP fixe non blacklistée, enregistrement SPF, DKIM, reverse dns configuré – et malgré çà, certains fournisseurs refusent mes courriels…
Je viens de remarquer que je n’ai pas configuré DMARC ceci dit…
en fait si j’avais le DMARC mais il était un peu vide.
Je viens de le mettre à jour avec:
_dmarc IN TXT « v=DMARC1;p=none;rua=mailto:postmaster@domaine.net;ruf=mailto:postmaster@domaine.net;fo=1 »
Salut, j’héberge mes emails depuis 2013 et je suis globalement d’accord, j’utilise aussi postgrey, et un relay pour des domaines spécifiques (Lié à Microsoft uniquement).
Avant 2019 ou 2020 il était assez facile de sortir des listes de Microsoft via un formulaire, mais du jour au lendemain toutes demandes étaient refusées. J’ai donc fini par utiliser un relay aussi, chez Infomaniak (gratuit vu que je suis chez eux), mais je le faisais aussi avant depuis Gandi (gratuit aussi), sauf que Gandi eux-mêmes ont des problèmes à ce niveau.
Pour information, en plus de _dmarc, j’utilise _arc, Google apprécie.
pour info sendinblue est aussi gratuit pour une limite de 300 emails par jour
https://fr.sendinblue.com/tarifs/
@Tetsumaki ok merci pour ton retour ! je connaissais pas arc, mais j’ai toujours eu de la chance avec gmail, pas eu besoin de l’ajouter encore – mais je garde le conseil sous le coude, au cas où ma chance tourne…
Bonjour
Merci pour cet article. C’est vrai qu’herberger son serveur mail est devenu bcp plus complexe qu’il y a une dizaine d’année.
Bon billet qui résume bien la situation.
J’ai exactement la même expérience ici, avec les mêmes solutions en place (sauf que je n’utilise pas Postfix/dovecot mais un couple serveur SMTP/POP que j’ai écrit moi-même en PHP) :
– SPF/DKIM/DMARC ;
– greylisting ;
– white list ;
– relay par envoyeur de confiance (orange dans mon cas) en cas de refus d’emails de la part de mon serveur.
Ca passe bien partout, sauf vraiment une infime minorité pour lesquels je n’ai pas de solution : en fait, j’ai juste un problème avec les rares emails qui passent par le relay et qui sont reçus par le destinataire et qui sont parfois refusés à cause du SFP. En effet, les serveurs d’Orange ne figurent pas dans mon enregistrement SPF et ça m’ennuie un peu de les ajouter. Mais bon, tant pis, je vis avec.
merci pour ton retour @xulops ! pourquoi çà t’ennuie de ne pas rajouter ton relai dans ton enregistrement SPF ?
Bonjour,
pour ma petite expérience, je m’auto-héberge grâce à Yunohost depuis quelques années et avec une adresse IP vpn sur le serveur avec un bon Rdns, je n’ai plus de soucis avec les mails.
@Anthony Dahanne, ça m’ennuie de rajouter mon relai dans mon enregistrement SPF car :
– faut ajouter toutes les IP des serveurs SMTP d’Orange (je suppose qu’ils n’en ont pas qu’un seul)
– ça veut dire que n’importe quel utilisteur d’orange (et ils sont nombreux) peuvent envoyer des mails avec mon nom de domaine sans que la vérification SPF ne le refuse. C’est donc une invalidation potentielle du SPF pour un bon nombre d’utilisateurs. En gros, ça veut dire que je ne considère pas les serveurs Orange comme source fiable pour mes mails.
@xulops oui, tu as raison, bon point. Si le relai courriel (orange dans ton cas) a lui meme des règles strictes (du genre: client@orange.fr ne peut que envoyer en tant que client@orange.fr) je pense que le risque d’abus est faible
Bonjour,
Je suis tout à fait d’accord avec ce constat d’une complexification sur les années 2010. À titre perso, j’auto-héberge depuis 2002 un serveur de messagerie. composé très classiquement sur une Debian autour de Postfix, avec roundcube à compter de 2012.
Ceci-dit, il y a 2 ans, alors que je comptais tout remettre à plat, j’ai décidé de voir ce que donnait Mailcow (The mailserver suite with the ‘moo’), solution de messagerie complète, et libre, pour Linux tournant sur Docker, et composée de Postfix/Dovecot/Sogo/Fail2ban/Rspamd et autres outils, avec support DKIM/ARC/CalDav/CarDav, tout pour faire un serveur de messagerie complet. Je l’ai très vite adopté., et je ne regrette pas. L’installation s’est faite très rapidement, il s’articule très bien avec Thunderbird, et sur deux ans je constate que cela fonctionne très bien, je gagne du temps :).
Sinon : poste.io
Je suis d’accord avec tout ce qui est dit ici 👍 Et plus particulièrement encore avec la quasi-obligation de passer par un relai ; Mailjet pour ma part également 🙂
L’auto-hébergement de mail est devenu (ou est resté, ne nous mentons pas) vraiment compliqué à maintenir… surtout lorsqu’on ne souhaite plus forcément passer tout son temps libre à administrer son serveur et à tester toutes les solutions (parfois loufoques) croisées sur la toile.
Triste constat d’après moi.