Voici le post-mortem d’un incident de délivrabilité vers Microsoft qui s’est produit chez nous à l’été 2024.

À partir du 9 juillet 2024, nous constatons que des spams sont envoyés avec des expéditeurs en @evolix.net vers Microsoft. On s’en rend compte car on reçoit des bounces mais aussi quelques réponses/plaintes d’utilisateurs sur une adresse qui existait bien (la plupart des adresses en @evolix.net utilisées n’existait pas).

Exemple d’un spam envoyé depuis une IP thaïlandaise :

Date: Thu, 11 Jul 2024 12:28:20 +0000
From: Service Plus Affiliate <xxx@evolix.net>
To: xxx@outlook.com
CC: xxx@outlook.com
Subject: Quick Savings Alert: 50% OFF Home Warranty Sale!
Return-Path: xxx@evolix.net
Message-ID: <Exf6vWO9DBgkI4iTvmHxvEhaLe@phvpthsdmaszxsx.evolix.net>

Ces spams sont envoyés par des adresses IPs complètement extérieures à nous, on n’y prête pas tellement attention dans un premier temps.

Les spams se poursuivent sur le même modèle mais en utilisant des expéditeurs en @XXX.evolix.net où l’enregistrement DNS XXX.evolix.net n’existe même pas.

À partir du 17 juillet, plusieurs serveurs remontent des problèmes de délivrabilité vers Microsoft en passant en jaune/rouge dans SNDS.

À partir du 19 juillet, des clients nous remontent des problèmes de délivrabilité vers Microsoft : les emails envoyés passent systématiquement dans la boîte Spam voire disparaissent.

Nous relayons les emails impactés par notre service « Zedmel », ce qui corrige une partie des problèmes.

Mais de plus en plus de clients nous remontent ce même problème.

Le 31 juillet 2024, après pas mal d’analyses, on se rend compte que le problème se produit quand on a « evolix.net » visible dans l’email envoyé : HELO, reverse DNS, etc.

Les emails sont bien acceptés par les serveurs SMTP de Microsoft, mais ils obtiennent une « note tueuse » maximale : X-MS-Exchange-Organization-SCL: 9
Ces emails sont alors mis en Spam ou en Quarantaine (suivant la politique des administrateurs Office365) c’est-à-dire invisibles pour le destinataire.

En effet, quand un serveur dédié n’a pas personnalisé son reverse DNS ou sa configuration Postfix, nous mettons par défaut un enregistrement en XXX.evolix.net

Les serveurs avec des domaines personnalisés ne sont pas impactés.

On se lance donc dans la personnalisation des domaines des serveurs impactés.

Mais en parallèle, les vagues de spams se poursuivent avec @evolix.net ou @XXX.evolix.net

Le 5 août 2024, nous décidons de changer nos enregistrements SPF et DMARC pour « evolix.net« 
pour « forcer » Microsoft à rejeter ces spams et faire cesser le problème à sa source.

Comme nous avons des centaines serveurs avec des adresses IPs de nombreux fournisseurs, et comme nous avons quelques process qui envoient des emails en @evolix.net nous avions mis un SPF qui autorise le monde entier :
evolix.net. IN TXT "v=spf1 include:spf.protection.evolix.net +all"
C’est une grosse erreur : SPF est un mécanisme d’autorisation, il ne faut jamaisautoriser le monde entier… au pire il vaut mieux ne pas mettre de SPF.
On passe donc notre SPF ainsi :
evolix.net. IN TXT "v=spf1 ptr include:spf.protection.evolix.net ~all"
(le champ « ptr » est déconseillé mais c’est notre seul moyen d’autoriser nos centaines de serveurs éparpillés partout, d’autres gros acteurs comme OVH l’utilisent aussi).
On passe aussi à une politique DMARC plus stricte pour avoir des rejets :
"v=DMARC1;p=reject;sp=reject"

Le 12 août 2024, après avoir finalement fixé les quelques process susceptibles d’envoyer
en @evolix.net vers l’extérieur on passe même le SPF en -all pour être sûr que
Microsoft coupe bien le robinet des spams :
evolix.net. IN TXT "v=spf1 ptr include:spf.protection.evolix.net -all"

Les vagues de spams se sont en fait arrêtées depuis quelques jours déjà.

Le 13 août, on prend contact avec l’équipe Postmaster de Microsoft pour expliquer tout ça et leur demander jusqu’à quand le blocage de « evolix.net » va durer.
On est habitué à avoir des réponses de leur part, mais dans ce cas nos demandes restent lettre morte.

On les relance à peu près toutes les semaines sans succès.
Pour mémoire, voici les « support request » toujours sans réponse à ce jour :

• Microsoft Support Request 7048679NNN : ouvert le 13 août, 7 relances (dernière le 23 septembre)
• Microsoft Support Request 7050730NNN : ouvert le 6 septembre, 2 relances (dernière le 23 septembre)

En parallèle, durant le mois d’août on s’assure que le problème est bien contourné partout.

Mais on aimerait tout de même que ce blocage chez Microsoft soit réglé.

Dans le merveilleux monde de la réputation des IPs et domaines au niveau SMTP, en général les blocages ne durent pas plus que 30 jours.
Vu que Microsoft ne nous répond pas, nous prenons notre mal en patience et espérons que le blocage disparaîtra début septembre au pire.

Le 6 septembre 2024, le problème est toujours présent et Microsoft ne nous répond toujours pas malgré nos relances.
Nous décidons de créer un compte Office365 (gratuit le 1er mois puis 15 EUR par mois) afin de contacter Microsoft en tant que « client ». Nous ouvrons donc le ticket 2409061410002NNN auprès du support niveau 1.
On obtient rapidement une réponse par email et même par téléphone, mais malheureusement cela reste du support de base. Même si l’interlocuteur maîtrise pas trop mal SPF/DKIM/DMARC il nous aiguille sur des fausses pistes.

Le 18 septembre 2024, on ouvre un nouveau ticket 2409181420002NNN auprès du support niveau 1.
On obtient également rapidement des réponses par email et par téléphone, mais cela reste basique.
On insiste en demandant que le problème soit escaladé. On nous demande de produire des rapports
à l’aide d’outils Microsoft assez fastidieux mais on ne lâche pas l’affaire.
On répond/relance le 19 septembre, le 23 septembre, le 25 septembre, le 30 septembre,
le 1er octobre, le 4 octobre, le 8 octobre, le 11 octobre…
On nous redemande de recréer des rapports déjà fournis, on nous demande poliment de patienter.

Le 15 octobre 2024 vers 16h, on reçoit un appel téléphonique de Microsoft :
« j’ai escaladé au support niveau 2, puis niveau 3, et ils me disent qu’ils ont enlevé le blocage, ça sera effectif dans 24h maximum »

Le 16 octobre au matin, le problème est toujours présent.
Mais à midi, on refait à nouveau un test avec Message-ID contenant « evolix.net » et effectivement : l’email aterrit en INBOX avec une « note tueuse » minimale : X-MS-Exchange-Organization-SCL: 1

On essaye évidemment d’en savoir plus : qu’est-ce qui a causé cela, mais on a toujours que le support niveau 1 en interlocuteur, et l’on comprend vite que l’on n’aura pas davantage d’informations.

Conclusion

Une grande partie des messageries est monopolisée par des gros acteurs qu’il est très difficile de contacter. Il faut éviter à tout prix d’avoir une raison de les contacter, donc il faut mettre des politiques SPF et DMARC strictes pour tous les domaines et sous-domaines que vous gérez. Si un domaine ou sous-domaine n’envoie pas d’email, il faut l’indiquer via SPF (« v=spf1 -all ») et annoncer une politique DMARC stricte (« v=DMARC1;p=reject;sp=reject »). Si vous avez des utilisateurs non aguéris ou des applis web publiques, il faut envisager de rate-limiter vos envois par exemple avec Postwd. Si vraiment besoin de les contacter pour un problème complexe, ouvrez un compte payant et contactez les en tant que client.

Les leçons qu’on en tire :

• il ne faut jamais utiliser +all dans un enregistrement SPF, au pire il est préférable de ne pas avoir de SPF…
• il faut mieux être radical avec des -all en SPF et reject en DMARC afin de détecter au niveau SMTP les problèmes et non pas avoir des emails mis en Spam ou pire « en quarantaine » (invisible pour l’utilisateur final)
• tout enregistrement DNS existant doit aussi avoir du SPF/DMARC, notamment pour indiquer qu’il n’est pas utilisé pour des emails
• analyser les entêtes de gros fournisseurs pour comprendre leurs vérifications antispams
• en dernier recours, il faut pouvoir changer les domaines / adresses IP utilisés pour l’envoi
• si un problème de réputation est toujours présent après 30 jours, c’est qu’il y a eu une opération manuelle
• propager la bonne parole pour « run your own mail server » afin de limiter ces monopoles malsains sur la messagerie

Filiale d’Evolix au Canada depuis 2015, Infogérance Evolix Inc propose des services d’hébergement et infogérance de serveurs Linux (Debian) pour le Canada.
Cette implantation au Canada permet de couvrir deux continents et va dans le sens d’une surveillance en 24/7.

Depuis notre arrivée, nous avons eu l’occasion de rencontrer et tisser des liens avec la très sympathique communauté Linuxienne et Pro-Libre du Québec, qui mérite ce petit article.

*** Rencontres Linux Québec : « qu’il vente, qu’il pleuve ou qu’il neige ! »

Depuis 21 ans, Martial Bigras, grand organisateur, et sa fine équipe, organisent des rencontres mensuelles entre les passionnés de Linux et de Logiciels Libres.
Tous les 1er mardis du mois, les participants se rejoignent pour un moment d’échange, que cela soit en présentiel sur Montréal ou à distance sur Big Blue Button.

Servis en français, les Meetups sont ouverts à tous, qu’importe votre région/continent. Malgré l’horaire des rencontres, 17h30/22h30 (heure de l’Est), il n’est pas rare d’y voir quelques participants francophones venant d’autres pays. Les sujets abordés couvrent aussi bien les bonnes pratiques du moment, des sujets d’actualités que des présentations d’outils Libres, le tout dans la bonne humeur et avec une volonté de partager.
Tout le monde est bienvenu qu’importe son niveau, du débutant aux gurus !

« Fun Fact : les Linux Meetups QC sont les plus gros Linux Meetups francophones en Amérique du Nord ! »

*** Chasse au trésor informatique (CTF : Capture The Flag) : 21 septembre 2024

Depuis les 5 dernières années, un CTF est organisé chaque année pour célébrer l’anniversaire des Linux Meetup Qc, cette année, cet évènement aura lieu le 21 septembre 2024 en mode hybride (présentiel et distanciel).
Evolix soutient cette initiative et fera encore partie des sponsors de l’évènement, de nombreux lots seront à gagner, des prix de présence et des récompenses en lien avec le CTF.

Il y aura une infrastructure spéciale en place pour l’occasion. Un grand merci à Dominique Derrier pour avoir travaillé pendant plusieurs mois afin d’inclure de nouveaux défis captivants et à Pascal Gad pour avoir testé au moins 10% des défis .
Certaines questions seront abordables pour tous les passionnés de Linux, d’autres demanderont de la créativité et d’ingénieuses solutions et les dernières feront appel à votre expertise de Guru Linux.
Le but est de découvrir ou redécouvrir de manière ludique des éléments de Linux.

Cette rencontre est gratuite et ouverte à tous, quel que soit votre niveau de compétence en Linux, du débutant à l’expert. Elle rassemble des personnes de diverses professions.

**** Journée internationale des Logiciels Libres

Cette année la journée des Logiciels Libres sera le 21 septembre, une raison supplémentaire de célébrer cette journée en participant au CTF !

**** Prochains évènements où croiser l’équipe d’Evolix de Marseille :
* Mini Debconf à Toulouse : https://wiki.debian.org/DebianEvents/fr/2024/Toulouse

Pour contacter Evolix Canada, en savoir plus sur nos services d’hébergement et infogérance de serveurs sous Debian ou échanger sur les Logiciels Libres, vous pouvez nous écrire sur hello@evolix.ca ou venir nous rencontrer en personne au 4284 De La Roche à Montréal. Café offert !

Nous avons eu le plaisir de participer à la DebConf24 qui s’est tenue à Busan en Corée du Sud. Cet événement, rassemblant plus de trois cents développeurs et contributeurs Debian du monde entier, s’est déroulé dans un cadre aussi chaleureux qu’inspirant, tant sur le plan des échanges que du climat (35ºN avec un climat subtropical humide, autant dire qu’on a eu chaud !).

Une semaine dédiée à la collaboration : DebCamp

Avant le début officiel de la conférence, la semaine du DebCamp nous a permis de nous concentrer sur des travaux en équipe. C’était une opportunité précieuse pour avancer sur des projets spécifiques. Nous avons eu l’occasion de travailler avec Athos Ribeiro sur l’amélioration de notre outillage d’empaquetage pour les librairies PHP. Athos a, en parallèle, posé les bases des tests automatisés (autopkgtest) pour cet outillage, et a entamé le processus pour devenir officiellement Développeur Debian.

De notre côté, nous avons contribué de manière significative avec plus de soixante-dix envois de paquets et l’interaction avec une quarantaine de bogues. Cependant, ces chiffres restent modestes par rapport à l’effort colossal d’empaquetage de homeassistant, initié par Edward Betts et rapidement soutenu par Thomas Goirand ainsi que de nombreux autres contributeurs. Ce projet a vu l’ajout de plusieurs centaines de paquets à Debian, avec un besoin encore plus important à venir.

Points forts de la DebConf24

La semaine de la DebConf a été marquée par une série de présentations et d’ateliers captivants. Voici quelques moments marquants :

• Le nouveau solveur APT : Julian Andreas Klode a présenté les dernières avancées du solveur pour le gestionnaire de paquets APT, en passant par un historique de son développement et en mettant en lumière les nouvelles fonctionnalités .
• Sequoia PGP : une alternative à GnuPG : Justus Winter a partagé ses travaux sur Sequoia, une alternative à GnuPG conforme aux RFC pour gérer OpenPGP. Cette présentation est arrivée à point nommé, juste avant la publication officielle de la RFC 9580, décrivant la dernière version d’OpenPGP (v6).
• Développement du noyau Linux : Helen Koike a animé un atelier où les participants ont pu mettre en place un environnement de développement pour le noyau Linux et proposer des correctifs, certains ayant même vu leur contribution acceptée dans l’heure dans la branche staging du noyau.
• AppArmor et les conteneurs : Leesoo Ahn a détaillé les applications d’AppArmor dans le contexte des conteneurs, offrant une perspective sur la sécurisation des environnements containerisés.
• Mise à jour en direct du noyau Linux : Emmanuel Arias et Santiago Ruano Rincón ont présenté leurs travaux pour permettre l’ajout de correctifs de sécurité au noyau Linux sans nécessiter de redémarrage, une avancée importante pour la disponibilité des systèmes.
• DebConf25 en Bretagne : Enfin, l’équipe bretonne a présenté les lieux de la prochaine DebConf qui se tiendra en juillet 2025, en Bretagne, un événement que nous attendons avec impatience.

Conclusion

Ces deux semaines intenses à Busan, que ce soit lors du DebCamp ou de la DebConf, ont été riches en enseignements, en collaborations fructueuses et en moments mémorables. La Corée du Sud, avec sa culture dynamique et accueillante, nous a offert un cadre exceptionnel pour renforcer les liens au sein de la communauté Debian. Nous revenons avec de nouvelles idées, des collaborations renforcées et une motivation renouvelée pour contribuer à ce projet qui nous passionne tant. Nous sommes impatients de continuer à échanger et à partager sur ces sujets dans les mois à venir, en attendant la DebConf25.

Nous avons eu l’opportunité de participer à la MiniDebConf Berlin 2024 du 14 au 21 mai. Cet événement a été un moment fort de rencontres, d’échanges et de travaux collaboratifs autour de la communauté Debian.

Une conférence riche en contenus

La MiniDebConf s’est déroulée sur une semaine, incluant deux jours de présentations et six jours d’ateliers. Une cinquantaine de participants étaient présents, avec des interventions variées et de grande qualité. Voici quelques présentations notables :

• What about Salsa?
• Breaking DKIM and BIMI with the 2008 Debian OpenSSL Bug
• An Early Review of the /usr Move

Toutes les vidéos des présentations sont déjà disponibles sur meetings-archive.debian.net
Des photos sont disponibles sur Salsa

Des ateliers productifs

Durant les ateliers, nous avons eu l’occasion de collaborer avec plusieurs membres actifs de la communauté Debian. Parmi les projets en cours :

• Johannes Schauer Marin Rodrigues (josch) a travaillé sur sbuild.
• Helmut Grohne (helmut) a avancé sur le déplacement de /usr.
• Gregor Herrmann (gregoa) a envoyé de nombreux paquets Perl et effectué du ménage sur Salsa.
• Alexander Wirt (formorer) a mis à jour Gitlab sur Salsa et corrigé quelques problèmes suite à la mise à jour du serveur par Julien Cristau.
• Philipp Kern (pkern) et plusieurs membres de l’équipe sécurité, dont Moritz Mühlenhoff (jmm) et Salvatore Bonaccorso (carnil), ont participé à un atelier d’une journée sur les aspects de sécurité.

Contributions d’Evolix

Nous avons principalement avancé sur la transition vers PHPUnit 11 en fermant plus de la moitié des 139 bogues remontés par Athos Coimbra Ribeiro (athos) après la reconstruction de tous les paquets concernés pendant la MiniDebConf de Belo Horizonte il y a deux semaines. Au total, durant cette semaine à Berlin, nous avons envoyé une soixantaine de paquets et fermé près de cent bogues.

• Rebuilds PHPUnit 11 par Athos Coimbra Ribeiro
• Bugs liés à PHPUnit 11
• MiniDebConf Belo Horizonte 2024

Ce fut une expérience enrichissante et stimulante, renforçant l’importance de la collaboration et de l’engagement communautaire dans le développement de Logiciels Libres. L’équipe Evolix est impatiente de poursuivre sur cette lancée et de participer aux prochains événements Debian, notamment en juillet à la DebConf 24 en Corée du Sud, et en novembre à la MiniDebConf Toulouse.