Dites-moi comment vous gérez votre messagerie et je vous dirai quel type d'hébergement vous utilisez.

Il y a une question que nous posons systématiquement aux clients qui changent d'opérateur, et elle ne concerne ni le nombre de cœurs, ni la quantité de RAM, ni le type de disque NVMe, ni même le débit annoncé. La question est bien plus simple : comment le courrier électronique est-il organisé ?

Il ne s'agit pas simplement d'une curiosité technique. La gestion des e-mails est probablement l'un des meilleurs tests pour comprendre le type de fournisseur d'hébergement auquel vous avez réellement affaire, car c'est à la fois l'un des services les plus difficiles à maîtriser et l'un des plus faciles à rendre dysfonctionnel de manière invisible.

Tout le monde constate la lenteur d'un site web. Un site inaccessible provoque immédiatement un appel téléphonique. En revanche, un courriel qui n'arrive pas à destination reste invisible : l'expéditeur croit l'avoir envoyé, le destinataire ignore qu'il devrait le recevoir, et le problème surgit peut-être trois semaines plus tard, lorsqu'une commande, un devis, une facture, une communication contractuelle ou une demande importante échoue.

C’est précisément cette invisibilité qui rend le courrier électronique particulièrement insidieux. Une infrastructure peut sembler fonctionner parfaitement, tandis qu’en silence, un certain pourcentage de messages sont classés comme spam, temporairement retardés, rejetés ou pénalisés par les principaux fournisseurs.

Le web actuel présente un problème largement connu. En plaçant nginx devant PHP-FPM, en ajoutant une couche de cache, en dimensionnant correctement les ressources et en corrigeant la base de données, on peut obtenir des résultats satisfaisants même sans infrastructure particulièrement sophistiquée.

Le numéro de la poste

Le courrier électronique est un écosystème distribué dans lequel votre service dépend du jugement d' autrui : Google, Microsoft, Yahoo, Spamhaus, les systèmes anti-spam du destinataire, les listes noires publiques et privées, les systèmes de réputation propriétaires et les politiques appliquées par les administrateurs individuels.

Vous pouvez disposer d'un matériel excellent, d'un stockage ultra-rapide et d'un serveur parfaitement accessible, et pourtant ne pas parvenir à acheminer un courriel parce que votre adresse IP a perdu en réputation, qu'un domaine n'est pas correctement authentifié, qu'un compte a été compromis ou que le comportement global de votre infrastructure ressemble soudainement à celui d'un réseau de spam.

C’est pourquoi la manière dont un fournisseur d’hébergement gère les courriels en dit long : il sait s’il possède une véritable expertise système en interne ou s’il assemble des composants achetés auprès de tiers ; il comprend le fonctionnement du service qu’il vend ou il le découvrira avec le client le jour où un problème surviendra.

Alors, établissons un classement honnête, du pire au meilleur.

Niveau 0 : tout sur la même machine, avec une seule adresse IP

C’est le scénario que nous voyons encore très souvent, et c’est celui dont nous devons fuir de toutes nos forces.

Un serveur. Sur celui-ci tournent Apache ou nginx, PHP, MySQL ou MariaDB, les sites web de dizaines ou de centaines de clients, et, sur la même machine et souvent avec la même adresse IP principale, même Postfix et Dovecot.

Le panneau de contrôle (cPanel, Plesk, DirectAdmin ou tout équivalent) présente cette architecture comme un avantage pratique : un endroit unique pour gérer votre domaine, votre site web, votre base de données, votre DNS et vos comptes de messagerie.

Pour l'utilisateur final, cela paraît simple. Pour le fournisseur, cela signifie avant tout concentrer tous les services sur une même infrastructure : une seule machine, une seule licence, quelques adresses IP et moins de composants à gérer.

Le problème, c'est que cette apparente simplicité crée une immense surface d'interdépendance.

C'est une bombe à retardement, et le mécanisme qui la fait exploser est presque toujours le même.

Sur deux cents sites WordPress, Joomla, Drupal, PrestaShop ou Magento, tôt ou tard, l'un d'entre eux sera compromis. Il ne s'agit pas de pessimisme, mais simplement d'une constatation statistique. Un plugin obsolète, un thème abandonné, une faille zero-day, un mot de passe réutilisé ou un identifiant FTP malencontreusement compromis suffisent.

De nos jours, les attaquants se contentent rarement de modifier la page d'accueil, comme c'était le cas il y a vingt ans. Cela n'apporte aucune valeur ajoutée. Il est bien plus efficace d'installer un module d'envoi d'emails PHP et de commencer à envoyer des messages d'hameçonnage ou des spams.

Ou vous pouvez abuser d'un formulaire de contact mal conçu. Ou même, il n'est pas nécessaire d'être compromis : il suffit d'un seul client qui décide d'envoyer une newsletter à quinze mille adresses achetées à partir d'une liste d'origine douteuse.

Dans tous ces cas, le trafic peut provenir de la même adresse IP utilisée par le courrier légitime d'autres clients.

À partir de ce moment, le problème d'un seul site devient le problème de tous.

Le véritable dommage n'est pas le spam : c'est la réputation partagée

La suite est essentiellement mécanique. Les pots de miel collectent les messages, les listes de réputation enregistrent l'activité et les principaux opérateurs associent cette adresse IP à un comportement indésirable.

Microsoft pourrait commencer à rejeter les messages ou à en limiter la réception. D'autres fournisseurs pourraient répondre directement par des erreurs SMTP. Gmail pourrait continuer à les accepter, mais les classera progressivement de manière plus stricte.

Et ce dernier scénario est l'un des plus dangereux, car techniquement, la livraison a déjà eu lieu.

Le serveur d'envoi reçoit un code SMTP positif. Le message a été accepté. Du point de vue de Postfix, la tâche est terminée.

C'est dommage que le message ait pu se retrouver dans le dossier spam du destinataire.

Voici le billet type :

« Vos courriels apparaissent comme ayant été distribués, donc de notre côté, tout est correct. »

Non. Cela signifie simplement que le serveur distant les a acceptés.

La délivrabilité et la livraison SMTP ne sont pas la même chose.

Un fournisseur de messagerie professionnel se doit de connaître cette différence et de disposer des outils nécessaires pour l'analyser.

Lorsque tout partage la même adresse IP, le risque se multiplie.

À ce moment-là, le fournisseur découvre trois choses coup sur coup.

Le premier problème est qu'il ne dispose pas d'une propriété intellectuelle de rechange véritablement prête à l'emploi.

L'attribution d'une seconde adresse IP à votre machine ne signifie pas que vous disposez d'une seconde identité SMTP opérationnelle. Une adresse IP dédiée au courrier électronique doit posséder un enregistrement PTR constant, une redirection DNS correcte, un HELO approprié, un SPF aligné et une réputation établie au fil du temps.

Transférer soudainement toutes les données vers une adresse IP inutilisée ne résout pas automatiquement le problème. Cela signifie repartir de zéro, sans aucune réputation, ce qui peut constituer un facteur de risque pour les filtres modernes.

La deuxième découverte est que le retrait de la plateforme n'est pas un bouton.

Lorsqu'une réputation est compromise, la première étape consiste à comprendre ce qui s'est passé, à stopper la source du spam, à documenter l'incident et à démontrer que ce comportement anormal ne se reproduira pas.

Demander à être retiré d'une liste noire sans avoir éliminé la cause du problème revient simplement à être de nouveau inscrit sur une liste noire quelques heures plus tard.

La troisième découverte, souvent la plus douloureuse, est que vous ne savez même pas d'où provient le spam.

Sur la même machine se trouvent des centaines d'hôtes virtuels, des dizaines ou des centaines de milliers de fichiers PHP, des tâches cron, des plugins, un CMS, des scripts personnalisés, des formulaires de contact et des applications.

Le journal du serveur de messagerie peut indiquer qu'un processus local a transmis un message à Postfix, mais relier ce message au site exact qui l'a généré peut nécessiter des outils de corrélation dont de nombreuses installations standard ne disposent tout simplement pas.

Lorsque ces outils font défaut, la solution devient radicale : bloquer l’envoi à tous jusqu’à ce que le coupable soit trouvé.

Et une centaine de clients innocents paient pour le problème d'un seul.

La probabilité n'est pas linéaire : elle s'accumule.

Il y a ensuite un point que presque personne ne prend en compte : la probabilité d'un accident augmente avec le nombre de services indépendants qui partagent la même réputation.

Si l'on suppose, par souci de simplicité, que chaque site a une probabilité annuelle de 1 % d'être compromis, avec deux cents sites, la probabilité qu'au moins un soit compromis au cours d'une année dépasse 86 %.

Cela ne signifie pas, bien sûr, que chaque compromission générera du spam. Cependant, cela signifie que l'exposition globale est radicalement différente de celle d'un site unique.

Une infrastructure de messagerie professionnelle doit être conçue en partant du principe qu'une faille de sécurité finira par se produire et en veillant à ce que les dégâts restent contenus.

Attribuer la même réputation au web et au courrier électronique revient à faire exactement le contraire.

Si votre fournisseur fonctionne de cette manière, la question à lui poser n'est pas :

« Est-ce possible ? »

La question est:

« Quand cela s’est-il produit pour la dernière fois, comment avez-vous localisé la source et combien de temps vous a-t-il fallu pour rétablir votre réputation ? »

La réponse, ou la gêne qu'elle occasionnera, vous en dira long.

Niveau 1 : séparation, ou le strict minimum

Le fournisseur le plus avisé a compris ce problème, souvent parce qu'il l'a déjà vécu.

Et faites ce qu'il faut : séparez-vous.

D'un côté, les serveurs web hébergeant les sites clients et les panneaux de contrôle. De l'autre, une infrastructure dédiée exclusivement à la messagerie, avec ses propres adresses IP, enregistrements PTR, configuration SMTP et système de réputation.

Le service postal se centralise : les clients n'ont plus forcément besoin de l'utiliser. mail.ilmiodominio.it Elles pointent vers la même machine que le site, mais sont gérées par une infrastructure indépendante.

Les avantages sont réels et devraient être reconnus.

La réputation est isolée. Si un site web est compromis, les dommages n'affectent pas automatiquement les adresses IP utilisées pour la messagerie électronique.

Les cycles de vie des serveurs deviennent indépendants. Vous pouvez mettre à jour PHP, migrer un site, changer de pile technologique ou redémarrer un serveur d'applications sans affecter IMAP, SMTP ni les boîtes aux lettres des utilisateurs.

Un niveau minimal de visibilité est instauré. Grâce à une infrastructure dédiée, il devient naturel de surveiller la file d'attente, le nombre de messages, les tentatives d'authentification, les volumes anormaux et les erreurs SMTP.

Le stockage des courriels est distinct de celui des sites web. Cette distinction est importante car un site web et une archive de courriels présentent des caractéristiques totalement différentes. Le premier évolue constamment mais peut être restauré grâce à du code et une base de données ; le second contient souvent des années de correspondance d'entreprise et croît de manière monotone.

La capacité peut être dimensionnée indépendamment. Le Web peut nécessiter du processeur, des processus PHP et un cache ; la messagerie électronique peut principalement nécessiter du stockage, des IOPS, de la RAM pour l’indexation et la capacité de gérer de nombreuses connexions IMAP simultanées.

Il s'agit donc d'une architecture bien meilleure que le niveau 0.

Mais ce n'est encore qu'un point de départ.

Si le fournisseur déplace le courrier vers un autre serveur mais continue de le gérer avec exactement les mêmes outils génériques qu'auparavant, il a amélioré la topologie sans modifier le modèle opérationnel.

Et c'est là que le véritable problème se pose.

Le vrai problème : les panneaux de contrôle généralistes comme Plesk, cPanel ou DirectAdmin

Pour comprendre pourquoi des outils comme cPanel, Plesk ou DirectAdmin présentent des limitations structurelles en matière de gestion professionnelle des courriels, il faut se rappeler à quoi ils étaient destinés.

cPanel a vu le jour en 1996. Plesk est apparu à la fin des années 1990 et s'est largement répandu au début des années 2000. DirectAdmin est arrivé en 2003.

Elles ont été créées pour résoudre un problème très précis : permettre à un utilisateur non administrateur système de gérer un hébergement mutualisé via une interface web.

C'est un objectif tout à fait légitime, et historiquement, ces produits ont très bien rempli leur fonction.

Le problème est de s'attendre à ce qu'une suite conçue pour gérer vingt sous-systèmes différents devienne simultanément un produit spécialisé pour chacun d'eux.

Un panneau de contrôle généraliste doit gérer les serveurs web, les hôtes virtuels, PHP, DNS, les bases de données, les utilisateurs FTP, les sauvegardes, les certificats TLS, la messagerie, les répondeurs automatiques, les listes de diffusion, les statistiques, cron et des dizaines d'autres fonctions.

C'est là sa force commerciale.

Mais c'est aussi sa limite technique.

Le courrier électronique moderne, quant à lui, est devenu un domaine spécialisé.

SPF, DKIM, DMARC, ARC, la réputation IP, la réputation de domaine, le greylisting, DNSBL, URIBL, la limitation de débit, l'authentification anormale, les logiciels malveillants, le phishing, les classificateurs statistiques, les boucles de rétroaction et les systèmes de réputation propriétaires ont transformé le simple serveur SMTP d'il y a vingt ans en une plateforme complexe.

Un tableau de bord qui doit également gérer WordPress, MySQL et DNS a peu de chances d'offrir la même profondeur d'outils de messagerie conçus spécifiquement à cet effet.

La dette technique accumulée

À cela s'ajoute l'inévitable dette technique accumulée au fil des décennies de compatibilité.

Configurations hiérarchisées, modèles générés automatiquement, comportements hérités des versions précédentes, systèmes de hooks et d'inclusion personnalisés qui doivent coexister avec les mises à jour automatiques.

Quiconque a géré ces systèmes pendant longtemps connaît le problème, même s'il ne l'admettra jamais en raison de conflits d'intérêts évidents.

Une modification apparemment anodine apportée à Postfix, Dovecot ou au moteur anti-spam ne peut pas toujours être effectuée directement sur le fichier de configuration, car ce fichier est généré par le panneau de configuration.

Vous devez ensuite comprendre où le fournisseur vous autorise à insérer la modification, quel modèle modifier, quelles mises à jour peuvent la remplacer et si la personnalisation continuera de fonctionner après une mise à jour majeure.

Dans une installation web classique, cela peut tout simplement être agaçant.

Dans un système de messagerie électronique comptant des milliers d'utilisateurs, cela devient une limitation opérationnelle souvent insurmontable ou qui vous oblige à accepter des compromis inacceptables.

Le coût, qui est plus élevé qu'il n'y paraît

Se pose ensuite la question économique.

Le modèle de licence de nombreux panels a évolué au fil des ans, et ce qui était un paiement unique il y a 10 ans est désormais lié au nombre de comptes, de domaines ou d'instances et appliqué par serveur.

Cela produit un effet curieux précisément au moment où le fournisseur tente d'améliorer son architecture.

Imaginez un serveur avec deux cents domaines.

Le fournisseur décide, à juste titre, de séparer le web du courrier électronique.

Si les deux serveurs doivent continuer à utiliser le même panneau de contrôle et si les mêmes deux cents comptes doivent exister à la fois sur les plateformes web et de messagerie, le coût des licences peut augmenter considérablement.

Le choix techniquement correct devient donc économiquement pénalisant et souvent impossible.

Et cela crée une incitation perverse : tout laisser dans la même machine coûte moins cher.

Le problème ne réside pas uniquement dans le coût de la licence. Il tient au fait que le modèle économique du produit peut, à terme, orienter l'architecture dans la direction opposée à celle qui serait techniquement préférable.

Les limites qui sont véritablement ressenties

Mais le coût, au final, est le moindre des problèmes.

Le problème sérieux survient lorsque quelque chose ne fonctionne pas.

Essayez de répondre à ces questions via l'interface standard d'un panel généraliste :

• Un client signale qu'il ne reçoit pas les courriels d'un expéditeur précis. Ils ne figurent pas dans le dossier des courriers indésirables ; ils n'arrivent tout simplement pas à destination. Quel contrôle les a bloqués, quel score ont-ils obtenu et pourquoi ?
• Une boîte aux lettres a été compromise. Quand l'activité anormale a-t-elle commencé ? À partir de quelles adresses IP s'est-elle authentifiée ? Combien de messages a-t-elle envoyés et vers quelles destinations ?
• La file d'attente contient quatre cents messages. Quels sont les messages légitimes et les spams ? Quels domaines sont bloqués ? Quel message d’erreur le destinataire renvoie-t-il ?
• Un domaine utilise 90 % de sa limite d'envoi. Le système nous avertit-il avant que le courrier ne nous parvienne, ou ne le découvrons-nous que lorsque l'envoi cesse ?
• Le client souhaite savoir ce qu'il est advenu du courriel reçu mardi à 14h32. Peut-on reconstituer l'intégralité de son parcours ou peut-on simplement affirmer, d'après le journal des transactions, qu'il semble avoir été livré ?
• Une adresse est soudainement authentifiée depuis deux continents différents en quelques minutes. Le système signale-t-il l'anomalie ou devons-nous la rechercher manuellement dans les journaux ?
• Un expéditeur légitime donné est bloqué sur dix domaines différents. Peut-on vérifier s'il existe une règle commune qui génère les faux positifs ?

Sur de nombreux panneaux à usage général, la réponse concrète est :

Vous vous connectez en SSH.

Et c'est là qu'apparaît une contradiction intéressante, presque un paradoxe.

Ce panneau permet aux clients non techniques de créer une boîte mail, de modifier un mot de passe ou de configurer un répondeur automatique.

Mais lorsqu'il s'agit de comprendre ce qui s'est réellement passé, ce travail est effectué en dehors du panneau de contrôle par une personne qui sait interpréter les journaux, à savoir un technicien.

Si cette personne existe, le prestataire peut toujours travailler.

S'il n'existe pas, le billet se termine par la phrase générique :

«Nous avons vérifié et de notre côté, tout semble correct.»

Cette phrase, lorsqu'elle n'est pas accompagnée de données, ne constitue pas un diagnostic.

C'est l'aveu de l'absence d'outils de diagnostic.

Le test décisif : « Pourquoi ce courriel n’est-il pas arrivé ? »

Il existe une question qui, à elle seule, distingue un service de messagerie véritablement géré d'un service simplement installé :

« Pourquoi ce courriel n'est-il pas arrivé ? »

Ne pas:

« Le serveur fonctionne-t-il ? »

Ne pas:

Postfix est-il actif ?

Ne pas:

« Le domaine dispose-t-il encore d'espace disponible ? »

Mais précisément :

« Qu’est-il arrivé à ce message en particulier ? »

Prenons l'un des billets les plus courants :

« Un de mes clients, sur plusieurs domaines, ne peut pas recevoir certains courriels à cause de blocages anti-spam. Existe-t-il une solution ? »

Peu d'informations. Peut-être quelques captures d'écran.

Il existe pourtant déjà un indice fondamental : « à travers différents domaines ».

Si différents domaines indépendants présentent exactement le même comportement face au même type de message, la probabilité que le problème réside dans la configuration de chaque domaine individuel diminue considérablement.

Nous devons rechercher ce que ces domaines ont en commun.

Et ce qu'ils ont souvent en commun, c'est le filtre.

Anatomie d'un faux positif

Un moteur anti-spam moderne prend rarement une décision sur la base d'une seule règle.

Il analyse de nombreux signaux : la réputation de l’adresse IP de l’expéditeur, l’authentification SPF et DKIM, l’alignement DMARC, la structure MIME, la présence d’URL, la réputation des domaines contenus dans le message, les pièces jointes, les caractéristiques linguistiques, les modèles statistiques, l’historique de l’expéditeur et de nombreux autres indicateurs.

Chacun de ces éléments contribue au verdict final.

Le modèle fonctionne très bien précisément parce qu'aucun signal unique n'a nécessairement besoin d'être décisif.

Mais cela a une conséquence importante : une seule règle à laquelle on accorde trop d’importance peut modifier l’ensemble du résultat.

Un message parfaitement légitime peut présenter dix indicateurs positifs : une bonne réputation, un SPF correct, un DKIM valide et un classificateur statistique qui le considère comme légitime.

Toutefois, si une seule caractéristique déclenche une règle avec un score suffisamment élevé, le message peut tout de même franchir le seuil de rejet.

Et quand cela arrive, ce n'est pas un message aléatoire qui est ciblé.

Une catégorie est concernée.

Tous les messages produits par la même plateforme. Tous les messages présentant une structure MIME spécifique. Tous les messages provenant d'un réseau spécifique. Tous les messages contenant une combinaison spécifique d'éléments.

C’est pourquoi ce symptôme apparaît souvent simultanément dans différents domaines.

Ce n’est pas une coïncidence.

C'est une signature diagnostique.

Que faut-il vraiment pour résoudre ce problème ?

Il vous faut au moins cinq outils, et aucun n'est optionnel.

1. Archives des messages bloqués. Vous devez pouvoir consulter le message original, le score final et les symboles ayant contribué au verdict. Si le message est simplement rejeté et disparaît, le diagnostic commence avec la moitié des informations manquantes.
2. La possibilité de reproduire le verdict. Vous devez pouvoir analyser le message avec le système antispam et vérifier précisément quelles règles sont déclenchées. Un diagnostic reproductible est bien différent d'une simple supposition.
3. Contrôle de la configuration. Identifier une mauvaise règle est inutile si le système ne permet pas de la modifier de façon permanente.
4. Un environnement dans lequel tester le correctif. Modifier à l'aveugle le comportement des filtres sur un serveur gérant des milliers de boîtes aux lettres revient à utiliser les clients comme environnement de test.
5. Tests de régression. Éliminer les faux positifs ne suffit pas. Il faut s'assurer que la modification n'a pas simultanément ouvert la porte au spam que la règle était censée intercepter.

Ce dernier point est fondamental.

Désactiver une règle est facile.

Le réparer, c'est une autre histoire.

La solution professionnelle est chirurgicale : le message légitime doit être transmis, tandis que le message véritablement indésirable doit continuer d’être bloqué.

Et cette différence doit être mesurable et démontrable.

Sans ces outils, le fournisseur ne peut pas affirmer avec certitude qu'un courriel a été correctement filtré.

Il ne peut que constater qu'il n'est pas arrivé.

Et c'est une différence énorme.

Niveau 2 : Infrastructure dédiée et outils spécialisés

L'étape suivante ne consiste pas seulement à transférer son courrier électronique sur un autre appareil.

Cela consiste à le traiter comme un service autonome.

Cela implique de concevoir séparément les systèmes SMTP, IMAP, anti-spam, antivirus, d'authentification, DNS, de surveillance, de stockage, de sauvegarde et de réputation.

Cela signifie également éliminer l'idée que le serveur de messagerie n'est qu'une fonctionnalité accessoire de l'hébergement web.

Un système sérieux doit pouvoir continuer à fonctionner même si l'ensemble de la plateforme web était arrêtée.

Le client peut migrer son site, changer la version de PHP, déplacer sa base de données ou modifier son CMS sans que cela n'ait le moindre impact sur les e-mails.

De même, un problème SMTP ne devrait pas compromettre WordPress, Prestashop ou Magento.

La séparation des domaines de défaillance est l'un des principes fondamentaux de l'administration système.

Le courrier ne devrait pas faire exception.

Notre approche professionnelle : la pile

Chez ManagedServer.it, nous avons décidé de rompre avec cette logique.

Pas de panneaux de contrôle généralistes pour gérer le cœur du service postal.

Nous utilisons une pile open source composée de logiciels spécialisés choisis composant par composant, configurés et intégrés dans le but de faire une seule chose : gérer les e-mails de manière contrôlable, observable et diagnostiquable.

Postfix et postscreen

Postfix est utilisé comme MTA.

En amont se trouve le postscreen , qui remplit une fonction extrêmement importante : éliminer une grande quantité de trafic automatisé avant qu’il n’atteigne les composants les plus coûteux de la chaîne SMTP.

Les bots qui ne respectent pas le protocole, les hôtes aux caractéristiques suspectes et les systèmes automatisés peuvent être identifiés sans mobiliser inutilement toutes les ressources du serveur.

Le principe est simple : il est inutile de soumettre chaque connexion Internet aux contrôles les plus coûteux si certains peuvent être éliminés dès l'entrée.

Pigeonnier et recherche en texte intégral

Dovecot gère les accès IMAP et POP3.

Lorsqu'une boîte aux lettres contient quelques centaines de messages, une recherche traditionnelle peut suffire.

Lorsque ce dossier contient des dizaines, voire des centaines de milliers de courriels accumulés sur dix ans d'activité commerciale, la situation change.

C’est pourquoi nous utilisons l’indexation plein texte via Solr , afin d’éviter que chaque recherche ne devienne un balayage linéaire de l’intégralité des archives.

La différence semble minime jusqu'au jour où un utilisateur recherche une facture de 2019 dans une boîte mail de trente gigaoctets.

rspamd

rspamd est le moteur anti-spam.

C'est probablement l'un des éléments qui différencient le plus l'infrastructure.

Non seulement parce qu'il est très efficace, mais surtout parce qu'il est interrogeable, configurable et observable.

Chaque message peut être associé aux symboles qui ont contribué au score final.

Cela vous permet de transformer une phrase comme :

«Le filtre le considère comme du spam»

dans:

« Ce message a reçu ce score pour ces raisons précises ».

C'est la différence entre un verdict incertain et un diagnostic.

État de l'antivirus, de la signature et du partage

ClamAV et amavis participent à la chaîne de contrôle antivirus, tandis qu'OpenDKIM gère la signature cryptographique des messages sortants.

Redis est utilisé pour les informations qui doivent être consultées et mises à jour rapidement, telles que les statistiques, la limitation du débit et les données partagées entre les composants.

Chaque composant remplit sa fonction.

C'est tout le contraire de l'approche monolithique dans laquelle une seule et même entité prétend régir tous les niveaux de l'infrastructure.

Le DNS, un composant que presque personne ne prend en compte

Il y a ensuite un détail qui, à première vue, semble secondaire, mais qui peut au contraire modifier radicalement la qualité du filtrage : le résolveur DNS récursif local.

Un système anti-spam effectue en permanence des requêtes DNS.

Vérifiez les listes noires, la réputation du domaine, les enregistrements SPF, DKIM, DMARC, le DNS inverse, et plus encore.

Si toutes ces requêtes sont envoyées via des résolveurs publics ou partagés, certaines sources de réputation peuvent limiter, rejeter ou modifier les réponses.

Le problème est particulièrement insidieux car le serveur de messagerie continue apparemment de fonctionner.

Il ne s'agit pas forcément d'une erreur évidente.

Tout simplement, certains signaux cessent de contribuer correctement au verdict.

Avoir un résolveur sous son contrôle signifie connaître le comportement des requêtes, réduire les dépendances externes et être capable de diagnostiquer également ce niveau de la chaîne.

Et c'est un parfait exemple de la différence entre installer un serveur de messagerie et gérer réellement une infrastructure de messagerie.

Redondance : Pourquoi « dédié » ne signifie pas nécessairement « fiable »

Séparer sa messagerie électronique du web est essentiel, mais ce n'est pas suffisant.

Si tous vos courriers électroniques résident sur un seul serveur, cela constitue un point de défaillance unique.

C’est pourquoi un architecte professionnel doit également penser en termes de redondance, de sauvegarde et de reprise après sinistre.

La question à se poser n'est pas seulement :

« Disposez-vous d'un serveur de messagerie dédié ? »

Mais aussi:

« Que se passe-t-il si ce serveur perd de l'espace de stockage ? »

« Combien de temps faut-il pour le reconstruire ? »

« Combien d'heures de courrier gaspillons-nous potentiellement ? »

« Existe-t-il une copie géographiquement distincte ? »

« Les sauvegardes sont-elles réellement vérifiées ? »

Effectuer une sauvegarde ne signifie pas nécessairement que vous pourrez la restaurer.

Une sauvegarde n'est utile que s'il existe une procédure réaliste pour l'utiliser et si le temps nécessaire à la restauration est compatible avec le service proposé.

Pour le courrier, c'est particulièrement important car les archives d'une entreprise peuvent contenir des années de documents et de conversations irremplaçables.

M@il Admin : le panel que les panels généralistes n’ont pas

Par-dessus cette pile, nous avons construit ce qui manque généralement aux outils spécialisés : une interface conçue précisément pour la façon dont nous gérons le courrier.

M@il Admin est l'interface développée en interne pour gérer cette infrastructure.

Il ne s'agit pas d'une version dérivée, ni d'un thème appliqué à un produit commercial, ni d'une couche visant à masquer un panneau existant.

Il s'agit d'un logiciel écrit de toutes pièces autour de la pile technologique qui existe réellement en dessous.

Et c’est précisément ce qui nous permet de proposer des fonctions qu’un panneau de commande généraliste pourrait difficilement offrir.

Accès multiniveau et multidomaine

L'administration de M@il est multiniveau et multidomaine.

Il existe différents profils d'accès : administration globale, administration de domaine et utilisateur final.

La séparation des données n'est pas simplement graphique.

Le filtrage est appliqué côté serveur en fonction des autorisations.

Cela signifie qu'un administrateur de domaine peut diagnostiquer sa propre messagerie sans pouvoir accéder aux informations appartenant à d'autres clients.

Il s'agit d'un aspect fondamental car l'objectif n'est pas seulement d'offrir plus de fonctionnalités à l'utilisateur.

Elle offre plus d'autonomie sans renoncer à l'indépendance et à la vie privée.

Observabilité : savoir ce qui se passe

Le principal problème de nombreuses infrastructures n'est pas que les événements ne soient pas enregistrés.

C'est juste que personne ne les voit.

Un journal contenant les informations pertinentes mais nécessitant vingt minutes de recherche avec grep, de corrélations manuelles et de connaissance de la structure interne du service est certes utile à l'administrateur système, mais il reste invisible.

L'observabilité apparaît lorsque ces informations sont organisées de manière à répondre rapidement aux questions opérationnelles.

Tableau de bord du flux de courrier

Le tableau de bord affiche en temps réel la charge sortante et l'état des files d'attente, avec une granularité adaptative.

L'objectif n'est pas de produire un graphique esthétiquement plaisant.

L'objectif est de répondre à une question en quelques secondes :

« Est-ce qu’il se passe quelque chose d’étrange en ce moment ? »

Une augmentation soudaine du nombre d'envois peut indiquer qu'il s'agit d'une newsletter légitime.

Cependant, cela peut aussi être le premier signe d'une boîte aux lettres compromise.

La différence apparaît lorsqu'on examine le domaine concerné, la boîte aux lettres, l'heure, la destination et l'historique des comportements.

File d'attente de courrier interrogeable

La file d'attente n'est pas simplement la sortie de postqueue.

Vous pouvez filtrer par expéditeur et destinataire, regrouper les messages par erreur et identifier instantanément les destinations qui posent problème.

Mais surtout, il est possible d'entrer dans les détails du message.

L'objet, l'expéditeur, les destinataires, les en-têtes, les résultats de la vérification, le corps du message et les pièces jointes deviennent des éléments consultables.

Vous pouvez également obtenir le fichier .eml original pour une analyse approfondie.

L'aperçu du contenu HTML est géré côté serveur, évitant ainsi le chargement automatique des ressources distantes.

C'est un détail important.

L'ouverture d'un aperçu d'un message suspect ne doit pas, en réalité, constituer une confirmation pour l'expéditeur de spam que la boîte mail existe et que son contenu a été ouvert.

Les URL restent visibles, ce qui vous permet d'identifier rapidement les domaines suspects et les tentatives d'hameçonnage.

La différence concrète est énorme.

Par:

« Il y a quatre cents messages en attente. »

Nous passons à la suite :

« Il y a quatre cents messages, dont trois cent cinquante proviennent d'un compte compromis et cinquante sont des messages légitimes temporairement rejetés par Microsoft. »

Le premier élément est l'information.

Le second est un diagnostic opérationnel.

Suivi des e-mails

Un message ne passe pas nécessairement par un seul processus.

Il peut entrer via SMTP, être analysé par un antivirus, passer par le moteur antispam, être réinjecté dans le système et générer différents identifiants à différentes étapes.

La recherche d'un seul identifiant de file d'attente peut donc donner une vue incomplète.

M@il Admin reconstitue le chemin du message et identifie sa direction : entrant, sortant, trafic interne ou notification d’échec de livraison.

Le résultat peut être exporté au format PDF et envoyé au client.

Quand quelqu'un demande :

« Qu’est-il arrivé au courriel de 14 h 32 ? »

nous ne voulons pas répondre par :

« D'après les journaux, tout semble correct. »

Nous souhaitons pouvoir produire un document relatant les événements réellement observés.

Volume d'envoi

Les soumissions sont regroupées par domaine et par boîte aux lettres.

Vous pouvez consulter les destinataires, les résultats et le pourcentage de consommation par rapport à la limite configurée.

Cela nous permet de distinguer rapidement les comportements normaux des comportements anormaux.

Un système de gestion qui envoie deux mille notifications par jour n'est pas forcément un problème.

Une boîte de réception personnelle qui passe soudainement de dix messages par jour à deux mille « oui ».

Le nombre absolu, pris isolément, est peu utile.

Le contexte est important.

Archives des messages bloqués

Tout ce qui est retenu par le filtre peut être analysé ultérieurement.

L'expéditeur, le destinataire, le score et les symboles ayant déterminé le verdict deviennent sujets à interrogation.

C’est précisément l’outil nécessaire pour répondre à la question :

« Pourquoi ce courriel n'est-il pas arrivé ? »

Sans archives, on ne peut que faire des suppositions.

Vous pouvez consulter les archives.

Tableau de bord anti-spam par domaine

Chaque domaine possède ses propres statistiques.

Le client peut voir le volume de trafic intercepté, les catégories de contrôles les plus fréquentes et l'évolution de cette tendance au fil du temps.

C'est aussi un moyen de rendre visible un service qui, autrement, ne serait remarqué que lorsqu'il tombe en panne.

Paradoxalement, un bon système anti-spam est presque invisible.

Si le système parvient à supprimer des milliers de messages indésirables sans générer de faux positifs, le client ne les verra tout simplement pas.

Les statistiques permettent de montrer ce qui se passe en coulisses.

Sécurité : détecter les problèmes avant que les clients ne les constatent.

La sécurité du courrier électronique ne se limite pas au blocage des virus et des tentatives d'hameçonnage.

L'un des principaux risques est le piratage de comptes légitimes.

Lorsqu'un attaquant obtient le mot de passe d'une boîte aux lettres, il n'a pas besoin de pirater Postfix ou Dovecot.

L'authentification se déroule normalement.

Du point de vue du protocole, il s'agit d'un utilisateur valide.

La différence se manifeste dans le comportement.

Surveillance des expéditions anormales

Une boîte de réception qui envoie normalement vingt messages par jour et qui en envoie soudainement mille à trois heures du matin, ça veut dire quelque chose.

Il n'est pas nécessairement compromis.

Mais cela mérite qu'on s'y attarde.

Pour cette raison, M@il Admin met en évidence les volumes et les tendances anormaux, vous permettant d'accéder à la boîte mail concernée avant que les dommages à la réputation ne soient évidents.

Accès anormaux

Le même principe s'applique aux authentifications.

Des adresses IP, des réseaux et des origines géographiques incompatibles peuvent être un indicateur fort de compromission.

Pour chaque adresse IP, vous pouvez obtenir des informations réseau et WHOIS, ce qui vous permet de distinguer rapidement une connexion mobile normale d'un serveur situé dans un centre de données à l'autre bout du monde.

Le point fondamental est le suivant :

Qui le remarque en premier ?

Dans une infrastructure sans observabilité, c'est souvent le destinataire.

Des erreurs SMTP commencent à apparaître. Les adresses IP perdent en réputation. Les courriels finissent dans les spams.

Ce n'est qu'à ce moment-là que quelqu'un enquête.

Mais à ce moment-là, le mal est déjà fait.

Avec les outils adéquats, il est possible d'intervenir sur un comportement anormal lorsqu'il ne s'agit encore que d'une anomalie.

Limites d'envoi granulaires

La limitation du débit doit être suffisamment intelligente pour ne pas traiter tout le monde de la même manière.

Une entreprise qui envoie dix courriels par jour n'a pas le même profil qu'un système de gestion qui envoie des milliers de notifications.

C’est pourquoi les seuils peuvent être définis par domaine et par boîte aux lettres individuelle, avec possibilité de dérogation.

L'objectif n'est pas d'empêcher les envois de masse légitimes.

L’objectif est de garantir qu’un compte compromis ne puisse pas transformer un incident local en un problème de réputation pour l’ensemble de l’infrastructure en quelques minutes.

Règles de l'expéditeur

Les listes d'autorisation et de blocage peuvent être appliquées à différents niveaux, ce qui vous permet de gérer les exceptions et les préférences sans avoir à intervenir systématiquement sur la configuration globale du système.

Les utilisateurs individuels peuvent autoriser ou bloquer indépendamment des expéditeurs spécifiques pour leur boîte aux lettres, tandis que les administrateurs peuvent définir des règles à l'échelle du domaine ou maintenir une vue d'ensemble des politiques actives sur l'ensemble de l'infrastructure.

Cela vous permet de résoudre rapidement de nombreux cas courants, tels que les faux positifs récurrents, les expéditeurs indésirables ou les exceptions spécifiques demandées par le client, sans nécessairement faire appel au support technique.

L'avantage n'est pas seulement opérationnel. Centraliser ces règles dans une interface dédiée réduit le nombre de tickets, rend les modifications plus traçables et, surtout, évite les solutions improvisées appliquées directement dans les fichiers de configuration, difficiles à documenter et potentiellement vulnérables lors de mises à jour ou de modifications ultérieures.

Politiques de mots de passe

De nombreux compromis ne commencent pas par une vulnérabilité sophistiquée.

Ils commencent par des mots de passe faibles, réutilisés ou déjà existants dans des bases de données compromises.

C’est pourquoi les politiques de mots de passe ne sont pas un simple élément cosmétique.

Ils font partie intégrante de l'architecture de sécurité.

Les exigences sont vérifiées lors du choix du mot de passe et le système peut générer automatiquement des identifiants robustes.

Formation au filtre bayésien

Le filtre ne reste pas figé dans sa configuration initiale.

Lorsqu'un utilisateur déplace un message dans le dossier spam, ce comportement peut contribuer à l'apprentissage du classificateur.

Le même phénomène se produit dans le sens inverse lorsqu'un message est récupéré parmi les spams.

Le système apprend ensuite du comportement réel des utilisateurs.

Et c’est d’autant plus important que la définition du « spam » n’est pas la même pour toutes les organisations.

Ce qui constitue un trafic commercial légitime pour une entreprise peut être totalement hors de propos pour une autre.

Opérationnalité : Faire les choses rapidement sans les faire mal.

Un bon panneau de commande ne se juge pas uniquement à la quantité de fonctions disponibles.

On l'évalue en fonction du nombre d'opérations répétitives qu'elle élimine et de la réduction de la probabilité d'erreur humaine.

M@il Admin inclut des outils pour l'importation en masse de boîtes aux lettres , les changements de mots de passe en masse , la génération de mots de passe forts et l'envoi de résumés.

Il vous permet d'envoyer aux utilisateurs les paramètres de configuration du client de messagerie , de gérer les quotas , d'appliquer des exceptions pour des boîtes aux lettres spécifiques et d'accéder directement à la messagerie web.

Une palette de commandes vous permet d'accéder rapidement aux fonctions principales sans avoir à naviguer constamment dans des menus et des sous-menus.

La surveillance des ressources système avec données historiques est également présente , car le comportement de l'infrastructure sous-jacente doit également être corrélé avec les événements observés dans le courrier.

À cela s'ajoute une base de connaissances intégrée de près de quatre-vingt-dix articles.

Documenter un produit au fur et à mesure de son développement produit également un effet secondaire extrêmement utile : cela vous oblige à vérifier que ce que l’interface promet correspond bien à ce que fait le code.

Et c’est précisément au cours de ce processus qu’il est possible de découvrir des incohérences, des comportements limitants et des défauts qui resteraient autrement invisibles.

La comparaison, en bref

La véritable différence : gérer ou simplement héberger

À ce stade, la différence devrait être évidente.

Nous ne comparons pas deux interfaces graphiques.

Nous ne discutons pas de l'esthétique de chaque bouton.

Nous comparons deux philosophies.

La première considère la messagerie électronique comme l'une des nombreuses fonctions incluses dans le forfait d'hébergement.

La seconde considère le courrier électronique comme un service d'infrastructure autonome, avec ses propres problèmes, outils, indicateurs et procédures.

Dans le premier modèle, le panel définit ce que le fournisseur peut faire.

Dans le second modèle, les besoins opérationnels définissent les outils à construire.

C'est une énorme différence.

Conclusion : ce n’est pas une question de budget, c’est une question d’attitude et de savoir-faire.

On pourrait faire valoir que la mise en place d'un tel système en interne requiert des compétences et du temps dont un hébergeur moyen ne dispose pas.

C'est vrai.

Mais c'est précisément là que la différence devient évidente.

Car le problème n'est pas que les outils n'existent pas.

Postfix, Dovecot, rspamd, Redis, Solr et les autres composants utilisés sont des logiciels matures, bien documentés et largement utilisés.

La question est de savoir s'il faut simplement les installer ou les comprendre suffisamment pour pouvoir les contrôler.

Acheter une licence, installer un panneau et cliquer trois fois sur « suivant » est beaucoup plus simple.

Il est beaucoup plus facile de dire au client :

«Il semble que la livraison ait été effectuée.»

que de reconstituer réellement ce qui s'est passé.

Il est plus simple de laisser votre navigateur web et votre messagerie électronique sur la même machine jusqu'à ce qu'il n'y ait plus de problème.

Il est plus facile d'imputer un problème à Gmail, Microsoft, l'expéditeur ou le filtre distant lorsqu'on ne dispose pas des outils nécessaires pour l'analyser.

Mais la commodité du fournisseur ne doit pas devenir un risque pour le client.

Un fournisseur d'hébergement vendant des services de messagerie électronique devrait comprendre comment fonctionne le courrier électronique.

Vous devriez être capable d'interpréter un score de spam.

Il devrait être capable de reconstituer le parcours d'un message.

Vous devriez être capable de faire la distinction entre un rejet SMTP et un problème de réputation.

Il devrait se rendre compte qu'une boîte a été compromise par le changement de son comportement.

Vous devriez être en mesure de déterminer pourquoi une règle de filtrage a classé un message d'une certaine manière.

Et elle devrait être en mesure de répondre aux questions des clients avec des données vérifiables.

Ne pas:

« À notre avis. »

Ne pas:

"Probablement."

Ne pas:

«De notre côté, tout semble correct.»

Mais:

« Ceci s’est produit, à ce moment précis, pour cette raison. »

Nous pensons également que cette fonctionnalité ne devrait pas rester confinée à l'interface de l'administrateur système.

Les informations utiles doivent être transformées en outils compréhensibles et accessibles à ceux qui administrent le service au quotidien.

Voilà pourquoi M@il Admin existe.

Non pas parce qu'il y avait une pénurie de panneaux sur le marché.

Il y a des dizaines de panneaux.

Dans notre façon de travailler, il nous manquait un outil capable de répondre à la question qui compte vraiment lorsqu'un client nous écrit à six heures du soir :

« Où est passé mon courriel ? »

Si votre fournisseur ne peut pas répondre à cette question par un fait concret (un journal, un score, un événement SMTP, une raison ou un rapport), alors vous avez déjà la réponse à la question initiale.

Dites-moi comment vous gérez les e-mails, et je vous dirai quel type d'hébergement vous proposez.