Comment configurer (en toute sécurité) les règles personnalisées de SpamAssassin dans Zimbra

Quel fichier Zimbra SpamAssassin devez-vous modifier ?

Pour Zimbra Collaboration Suite 8.5 et versions ultérieures, la documentation de Zimbra indique que les personnalisations locales de SpamAssassin peuvent être stockées dans un répertoire spécifique /opt/zimbra/data/spamassassin/localrules. Un fichier de règles avec l' .cfextension `.zimbra` peut y être placé ; l'exemple de Zimbra utilise un fichier distinct pour une règle personnalisée. Les versions antérieures de Zimbra utilisaient des emplacements différents ; vérifiez donc la version et le répertoire sur votre serveur avant toute modification. La structure du package peut également varier selon la version ou le déploiement.

Ce guide ajoute une petite règle réversible à l'échelle du site, vérifie sa syntaxe, recharge le service d'analyse du courrier et vérifie la bonne réception du message. Il suppose que vous administrez le serveur Zimbra MTA. Si vous utilisez plusieurs serveurs MTA, appliquez le fichier et rechargez SpamAssassin sur chaque serveur analysant le courrier entrant.

Le guide des règles personnalisées SpamAssassin de Zimbra documente le chemin d'accès aux règles locales et la zmamavisdctl restartcommande. Ses recommandations anti-spam distinguent la configuration ZCS 8 de celle de ZCS 8.5 et versions ultérieures.

Qu'est-ce qu'une règle personnalisée modifie ?

Une règle SpamAssassin détecte une caractéristique d'un message, lui attribue un nom symbolique et un score. SpamAssassin combine ce score avec d'autres résultats de tests. Zimbra applique ensuite ses seuils de traitement du spam configurés. Une règle ne garantit pas, à elle seule, qu'un message soit placé dans le dossier Courrier indésirable ou rejeté : le reste du score du message et les paramètres de votre serveur sont également déterminants.

Cette distinction est importante lors du choix d'un score. Commencez par une valeur modeste, examinez les faux positifs et augmentez-la uniquement lorsque les tests confirment la fiabilité du signal. Évitez de copier un score élevé d'un exemple sans avoir préalablement vérifié votre propre seuil de spam et de rejet.

Avant de modifier quoi que ce soit, que devez-vous vérifier ?

• Version et chemin d'accès : vérifiez votre version de Zimbra et son /opt/zimbra/data/spamassassin/localrulesexistence. Le chemin d'accès indiqué dans ce guide s'applique à ZCS 8.5 et versions ultérieures, conformément à la documentation de Zimbra. Ne présumez pas qu'il s'applique aux versions antérieures.
• Quel serveur analyse le courrier électronique ? Identifiez chaque MTA exécutant Amavis/SpamAssassin. Une règle installée sur un serveur n’apparaît pas automatiquement sur un autre MTA indépendant.
• Intention de la règle : Choisissez un signal de message spécifique et reproductible. Évitez les règles qui correspondent à des mots génériques tels que « gratuit » ou « offre » sans preuve supplémentaire.
• Restauration : Enregistrez tout fichier existant avant de le modifier. Utilisez un nom de fichier descriptif pour chaque nouvelle règle et évitez d’écraser .cfaccidentellement un fichier existant.

Il s'agit de personnalisations au niveau du serveur, et non de filtres de messagerie. Tous les utilisateurs dont les courriels transitent par le scanner configuré peuvent être concernés.

Comment rédiger une règle simple ?

SpamAssassin prend en charge différents types de règles, notamment : ` <header>` header, `<sub> body`, uri`<sub>` et ` meta<body>`. Une règle d'en-tête est utile lorsqu'un sujet ou une valeur d'en-tête spécifique constitue le signal. Une règle de corps analyse le contenu textuel du message ; la documentation de SpamAssassin précise que les règles de corps classiques s'appliquent au texte décodé et considèrent par défaut le sujet comme faisant partie du corps. Utilisez une règle d'URI lorsque la condition concerne spécifiquement les liens.

Voici un exemple volontairement restreint qui attribue un petit nombre de points lorsqu'un objet de message test contient une expression unique. Remplacez cette expression par un signal que vous avez vérifié dans vos propres courriels ; cet exemple ne constitue pas une signature anti-spam générique.

header LOCAL_SUBJECT_REVIEW Subject =~ /\bExample Vendor Alert\b/i
score LOCAL_SUBJECT_REVIEW 2.0
describe LOCAL_SUBJECT_REVIEW Subject contains the review phrase

Le nom symbolique doit être unique et comporter des lettres, des chiffres et des tirets bas. Cette headerligne définit la correspondance, scoredétermine les points ajoutés en cas de succès et describefournit une explication dans le rapport de SpamAssassin. La description doit être concise et indiquer clairement aux autres administrateurs la raison d'être de ce test.

La documentation de référence de SpamAssassin décrit la syntaxe des règles d'en-tête et de corps, le comportement du score et les détails des expressions régulières. La version de Zimbra SpamAssassin installée peut différer de la documentation Apache la plus récente ; par conséquent, évitez d'utiliser les nouvelles fonctionnalités de règles tant que leur compatibilité locale n'est pas confirmée.

Comment installer la règle sur Zimbra 8.5 et versions ultérieures ?

1. Connectez-vous au MTA avec un compte administrateur pouvant basculer vers le compte de service Zimbra.
2. Vérifiez le répertoire d'installation et le répertoire des règles locales. Par exemple :
   su - zimbra
ls -ld /opt/zimbra/data/spamassassin/localrules
3. Choisissez un nom de fichier qui n'existe pas déjà, par exemple local_subject_review.cf. Vérifiez d'abord :
   ls -l /opt/zimbra/data/spamassassin/localrules/local_subject_review.cf
   s'il existe déjà, examinez-le et choisissez un autre nom au lieu de l'écraser.
4. Créez le nouveau fichier en tant zimbraqu'utilisateur avec votre éditeur, et ajoutez les trois lignes de règle ci-dessus :
   vi /opt/zimbra/data/spamassassin/localrules/local_subject_review.cf
5. Enregistrez le fichier, puis vérifiez le propriétaire et le contenu :
   ls -l /opt/zimbra/data/spamassassin/localrules/local_subject_review.cf
cat /opt/zimbra/data/spamassassin/localrules/local_subject_review.cf

Si le répertoire est absent, arrêtez-vous et vérifiez la version de Zimbra ainsi que sa configuration. Ne créez pas de répertoire portant un nom similaire à un emplacement aléatoire ; SpamAssassin ne le chargera pas forcément.

Comment devez-vous le valider et le recharger ?

Exécutez la vérification syntaxique de SpamAssassin avant de recharger. La documentation en ligne de commande d'Apache décrit cette --lintcommande comme une vérification de la syntaxe des règles et de la configuration. En tant qu'utilisateur Zimbra, exécutez-la spamassassin --lintsi l'exécutable correspondant est disponible dans l'environnement Zimbra. Si la commande est introuvable ou ne charge pas la configuration de Zimbra, localisez l'exécutable fourni et utilisez le chemin de configuration approprié à votre version plutôt que de tester sur une installation système non liée. Un résultat de vérification syntaxique positif ne garantit pas que votre modèle correspondra aux messages que vous souhaitez envoyer.

La documentation de SpamAssassin explique l'option `lint`. Une fois la validation réussie, redémarrez Amavis en tant zimbraqu'utilisateur afin que l'analyseur charge les règles modifiées.

zmamavisdctl restart

L'exemple de règles personnalisées de Zimbra utilise cette commande de service. Sur une installation multi-MTA, répétez le déploiement du fichier et le redémarrage du service sur chaque scanner concerné. Si votre version utilise une commande de service différente, consultez la documentation Zimbra correspondante.

Comment savoir si la règle fonctionne ?

Envoyez un message de test contrôlé via la même route entrante que celle utilisée par les utilisateurs. Utilisez l'objet exact défini dans la règle pour un message, puis envoyez un message similaire sans cet objet. Examinez les en-têtes originaux du message reçu, notamment X-Spam-Statusla valeur de l'en-tête LOCAL_SUBJECT_REVIEWet la contribution au score. Comparez les deux messages et vérifiez par quel chemin Zimbra les a distribués.

Le résultat est utile si la règle n'apparaît que dans le test prévu et si le score total correspond au traitement attendu. Si le nom du test est absent, vérifiez que le message a bien transité par ce MTA, que le nom du fichier se termine par `.localrules`, que .cfle fichier se trouve dans le répertoire `localrules` approprié, que l'analyseur a redémarré correctement et que l'échantillon correspond bien à l'expression régulière. N'oubliez pas que les clients de messagerie peuvent masquer les en-têtes de diagnostic dans leur affichage normal ; ouvrez le code source du message ou les en-têtes complets.

Que se passe-t-il si la règle génère de faux positifs ou ne correspond à aucune valeur ?

• Trop de messages légitimes correspondent : réduisez le score ou restreignez l’expression régulière. Testez avec des exemples de courriels souhaités et indésirables avant d’augmenter le score.
• Aucun message ne correspond : vérifiez le nom d’en-tête exact, l’expression régulière insensible à la casse, l’échappement, l’extension de fichier, le chemin d’accès et le redémarrage du service. Pour les URL, privilégiez l’évaluation d’une urirègle plutôt que de supposer qu’une règle du corps constitue le meilleur test.
• Lint signale une erreur : corrigez la ligne indiquée et relancez lint avant de redémarrer. Une règle personnalisée mal formée peut entraîner des problèmes de configuration ou empêcher le chargement des tests attendus.
• Une règle apparaît, mais le message reste dans la boîte de réception : cela peut être normal si les points ajoutés ne font pas dépasser le seuil de spam configuré. Consultez le X-Spam-Statusscore complet et les seuils de traitement locaux.

Pour annuler les modifications, supprimez uniquement le fichier personnalisé que vous avez ajouté, puis redémarrez Amavis. Si vous avez modifié un fichier existant, restaurez sa copie de sauvegarde et validez la configuration avant de la recharger. Conservez un bref historique des modifications indiquant l'objectif de la règle, son score, les messages de test et le nom du fichier de restauration afin que les futurs administrateurs puissent la réévaluer.

Limites de version et de comportement

La documentation de Zimbra relative aux chemins d'accès couvre explicitement ZCS 8.5 et versions ultérieures et décrit une configuration différente pour les versions antérieures. La version exacte de SpamAssassin et les seuils fournis dépendent de l'installation. Une règle valide peut également se comporter différemment selon le format des messages, les relais et les chemins de messagerie. Consultez la documentation de votre version installée, effectuez des tests sur un itinéraire contrôlé et basez votre analyse sur les en-têtes des messages et des exemples de faux positifs réels, plutôt que sur le seul texte de la règle.