Rspamd avec Postfix : comprendre le filtrage antispam
Associer Rspamd et Postfix permet d’analyser les messages au moment où le serveur de courrier les reçoit ou les transmet. Postfix gère le transport ; Rspamd examine les contenus et renvoie notamment un score, des symboles détectés et une action recommandée.
Dans une petite structure, cette séparation facilite les réglages : l’administrateur peut ajuster le filtrage antispam sans remplacer le serveur de messagerie. Selon la documentation de Rspamd, l’intégration Milter constitue une méthode courante pour faire communiquer les deux services.
Le rôle du protocole milter
Le protocole milter sert d’interface entre Postfix et un filtre externe. À la réception d’un message, Postfix transmet à Rspamd les éléments nécessaires à l’analyse, puis applique la réponse reçue selon sa configuration.
Concrètement, une entreprise peut choisir de marquer un courriel suspect plutôt que de le rejeter immédiatement. Cette approche laisse une trace exploitable dans les en-têtes et limite le risque de bloquer un message légitime à cause d’une règle trop stricte.
Avant le déploiement, il faut vérifier que le service Rspamd écoute sur l’adresse et le port prévus, et que Postfix peut les joindre. Le port 11332 est fréquemment utilisé pour un point d’accès Milter, mais il dépend de la configuration réellement active.
Repères pour l’intégration Milter :
- Adresse d’écoute du service Rspamd
- Port Milter réellement configuré
- Version de protocole acceptée par Postfix
- Action prévue si le filtre devient indisponible
Configuration de Postfix et choix des actions
Une fois le rôle de chaque service défini, la configuration doit préciser comment Postfix contacte Rspamd et réagit à ses réponses. Les paramètres Milter sont généralement déclarés dans la configuration Postfix, puis le service est rechargé après vérification de la syntaxe.
Relier les deux services sans interrompre le courrier
Pour un serveur qui reçoit du courrier depuis Internet, l’administrateur configure le filtre sur le chemin SMTP entrant. Les messages soumis par des utilisateurs authentifiés peuvent aussi nécessiter un traitement distinct, notamment pour éviter d’appliquer aux courriels sortants les mêmes politiques qu’aux messages entrants.
Selon la documentation de Postfix, les paramètres Milter servent à déclarer les filtres et le comportement attendu en cas d’indisponibilité. Un réglage permissif favorise la continuité du courrier, tandis qu’un échec temporaire protège davantage le serveur contre les messages non analysés.
Le choix dépend du contexte. Une plateforme qui privilégie la disponibilité peut accepter temporairement les messages si Rspamd est arrêté ; un service soumis à des règles strictes peut préférer différer leur traitement jusqu’au rétablissement du filtre.
Options à comparer pour la disponibilité :
- Acceptation temporaire sans analyse antispam
- Refus temporaire avec nouvelle tentative d’envoi
- Surveillance des journaux et alertes de service
- Test de panne avant mise en production
Le tableau distingue les deux choix opérationnels sans imposer une politique universelle.
| Comportement | Effet immédiat | Point de vigilance |
|---|---|---|
| Mode permissif | Le traitement du courrier continue | Des messages passent sans analyse |
| Échec temporaire | Le serveur expéditeur peut réessayer | Retards possibles en cas de panne prolongée |
| Rejet définitif | Le message n’est pas accepté | À réserver aux politiques clairement définies |
| Marquage du message | Le courriel reste consultable | Les règles de tri doivent être cohérentes |
DKIM, DMARC et authentification SMTP
Le filtrage des messages ne se limite pas à repérer les contenus indésirables. Il s’inscrit dans une configuration plus large où l’authentification SMTP, la signature DKIM et les politiques DMARC contribuent à distinguer les expéditeurs légitimes des usurpations.
Signer les messages sortants avec Rspamd
Rspamd peut prendre en charge la signature DKIM des messages sortants, ce qui évite parfois d’ajouter un service de signature séparé. Cette option doit être configurée avec les clés adaptées au domaine et accompagnée d’une publication correcte de la clé publique dans le DNS.
Un scénario fréquent consiste à faire analyser les messages par Rspamd, puis à signer ceux qui proviennent des utilisateurs autorisés. La séparation entre réception publique et soumission authentifiée aide à éviter qu’un serveur ne signe à tort des messages externes simplement relayés.
Selon les recommandations usuelles de déploiement de Rspamd, la politique doit aussi tenir compte des en-têtes Milter transmis par Postfix. Des macros absentes ou incompatibles peuvent priver l’analyse de contexte utile ; le dépannage commence donc par comparer les journaux des deux services.
Contrôles utiles pour les domaines expéditeurs :
- Correspondance entre domaine d’envoi et signature DKIM
- Enregistrement DMARC cohérent avec SPF et DKIM
- Soumission SMTP réservée aux comptes authentifiés
- Vérification des en-têtes ajoutés aux messages sortants
DMARC s’appuie sur les résultats SPF et DKIM ainsi que sur leur alignement avec le domaine visible par le destinataire. Une politique plus stricte ne devrait être activée qu’après examen des rapports et des flux légitimes de l’organisation.
| Mécanisme | Ce qu’il vérifie | Rôle dans le déploiement |
|---|---|---|
| Authentification SMTP | Identité du compte qui soumet le courrier | Contrôler l’envoi par les utilisateurs |
| SPF | Serveurs autorisés à expédier pour un domaine | Évaluer l’origine technique du message |
| DKIM | Signature cryptographique associée au domaine | Vérifier l’intégrité et l’origine déclarée |
| DMARC | Alignement et politique de traitement du domaine | Orienter le traitement des échecs d’authentification |
Apprentissage et dépannage de Rspamd
Après la mise en service, la qualité du filtrage dépend aussi des retours d’usage. Un message classé à tort comme indésirable peut servir à corriger les règles, tandis que les courriels confirmés comme spam affinent progressivement l’apprentissage.
Exploiter les retours des utilisateurs
Dans une installation avec Dovecot, l’apprentissage peut passer par le plugin antispam ou par une action manuelle dans un webmail comme Roundcube ou SOGo. Le principe est simple : les utilisateurs déplacent les messages entre les dossiers de courrier indésirable et de courrier légitime, puis le mécanisme d’apprentissage traite ce retour.
Une petite équipe informatique peut, par exemple, commencer par examiner chaque semaine les faux positifs signalés. Cette routine évite de modifier les seuils sur la base d’un incident isolé et aide à repérer une règle trop agressive ou une source d’envoi mal évaluée.
Diagnostiquer les erreurs courantes
Lorsqu’un message n’est pas analysé, il faut vérifier dans l’ordre la disponibilité de Rspamd, la connectivité depuis Postfix, les paramètres Milter et les journaux des deux applications. Les erreurs de socket, les ports incorrects et les permissions insuffisantes figurent parmi les pistes concrètes à examiner.
Si le score paraît incohérent, comparez les symboles renvoyés avec les en-têtes du message et confirmez que Postfix transmet les métadonnées attendues. Les tests doivent couvrir la réception entrante, l’envoi authentifié, les signatures DKIM et le comportement choisi lors d’une panne.
Une procédure de dépannage efficace consigne le message concerné, l’heure, les journaux utiles et le résultat attendu. Cette méthode rend les corrections reproductibles et permet de distinguer un problème de configuration d’une règle antispam mal adaptée.
Déployer Rspamd en production avec méthode
Après les premiers réglages, la mise en production gagne à se faire progressivement. Une période d’observation permet de comparer les décisions du filtre aux messages réellement reçus, avant d’appliquer des rejets plus stricts.
Procéder par étapes vérifiables
Commencez par relier Postfix à Rspamd et confirmez que les messages traversent le filtre. Ensuite, observez les scores, vérifiez les journaux et testez séparément les courriels entrants et ceux envoyés par les utilisateurs authentifiés.
Le suivi ne s’arrête pas au lancement. Il faut conserver une procédure de retour arrière, surveiller les files d’attente et documenter les modifications de seuils, de règles ou de clés DKIM afin de comprendre rapidement une évolution du comportement.
Repères de mise en production progressive :
- Validation des flux entrants et sortants
- Observation des scores et des faux positifs
- Contrôle des signatures DKIM et rapports DMARC
- Procédure écrite de retour arrière
Cette discipline est particulièrement utile lorsqu’un serveur héberge plusieurs domaines : une modification globale peut toucher des expéditeurs qui n’ont pas les mêmes usages. Des tests ciblés réduisent les surprises et facilitent le dépannage sans interrompre les échanges.