Migration de SpamAssassin vers Rspamd : retour d’expérience

1. Pourquoi remplacer SpamAssassin ?

Sur mon serveur mail, le filtrage antispam reposait depuis longtemps sur SpamAssassin.

Le système fonctionnait, mais j’ai souhaité passer à Rspamd, notamment pour bénéficier :

  • d’un moteur plus moderne ;
  • d’une analyse plus complète des messages ;
  • d’une meilleure intégration SPF, DKIM et DMARC ;
  • d’un système Bayes/statistique performant ;
  • d’une interface Web permettant de comprendre précisément les décisions du moteur ;
  • d’une configuration beaucoup plus facilement ajustable.

La migration s’est toutefois révélée plus complexe qu’un simple remplacement de SpamAssassin.

Le principal problème rencontré n’a d’ailleurs pas été Rspamd lui-même, mais l’interaction avec Redis et un site WordPress hébergé sur le même serveur.


Lire la suite “Migration de SpamAssassin vers Rspamd : retour d’expérience”

🛡️ Mise en place et validation d’un anti-spoofing mail efficace (Postgrey + SPF entrant + SpamAssassin)

L’anti-spoofing mail est un enjeu majeur lorsqu’on auto-héberge son serveur de messagerie. Malgré la mise en place de SPF et DKIM en sortie, il arrive encore de recevoir des emails semblant provenir de son propre domaine.
Dans cet article, je détaille une mise en place réaliste et testée en conditions réelles d’un anti-spoofing mail efficace, basé sur Postgrey, SPF entrant et SpamAssassin, sans faux positifs ni rejet SMTP agressif.


🎯 Objectif

L’objectif n’est pas de bloquer aveuglément, mais de construire une chaîne de filtrage cohérente qui :

  • réduit drastiquement le spam automatisé,
  • détecte les tentatives d’usurpation d’identité,
  • laisse passer les emails légitimes,
  • délègue la décision finale à un moteur de scoring.

La solution repose sur trois briques complémentaires :

  1. Postgrey (greylisting)
  2. SPF entrant (policyd-spf)
  3. SpamAssassin (analyse et décision)

Lire la suite “🛡️ Mise en place et validation d’un anti-spoofing mail efficace (Postgrey + SPF entrant + SpamAssassin)”

Migration Debian 12 → Debian 13 (Trixie) Retour d’expérience réel, problèmes et solutions

Contexte

Migrer un serveur Debian en production n’est jamais anodin.
Dans mon cas, le passage de Debian 12 (Bookworm) à Debian 13 (Trixie) a été beaucoup plus brutal que prévu : services cassés, configurations obsolètes, dépendances Python disparues, et même des logiciels pourtant “standards” devenus incompatibles.

Voici un retour d’expérience concret, avec tous les pièges rencontrés, leurs solutions, et une checklist post-migration pour éviter d’y passer des heures comme moi.

Situation de départ

Serveur distant (ovh) avec :

  • Apache + PHP (WordPress)
  • Postfix + Dovecot + Roundcube
  • Webmin / Virtualmin
  • Fail2Ban, firewalld / nftables
  • Serveur Minecraft via Crafty
  • Docker (partiel)
  • ProFTPD

Migration effectuée via upgrade in-place.

1️⃣ Sites WordPress en erreur 503

🔍 Diagnostic

Commandes utilisées pour identifier la cause
curl -I https://monsite.tld
sudo systemctl status apache2
sudo tail -n 50 /var/log/apache2/error.log
sudo systemctl status php8.4-fpm

🧠 Cause

Apache fonctionnait, mais PHP-FPM n’était pas correctement configuré / socket absent.

Lire la suite “Migration Debian 12 → Debian 13 (Trixie) Retour d’expérience réel, problèmes et solutions”