Passer à Rspamd n'est pas forcément une bonne idée. SpamAssassin peut rester une solution adaptée si les règles sont stables et la charge de maintenance raisonnable ; Rspamd est particulièrement intéressant pour les nouvelles installations, l'intégration de Milter et les environnements à évolutivité contrôlée. Ce ne sont pas les scores repris qui sont déterminants, mais les erreurs de classification, les dépendances et un fonctionnement parallèle sécurisé. Rspamd évalue les messages à l’aide de symboles et propose des actions dont la mise en œuvre est définie par l’intégration au MTA.
Cibles des filtres anti-spam et erreurs inévitables
Un filtre anti-spam évalue les messages dans le flux de messagerie en fonction de caractéristiques techniques et de contenu. Selon le produit, cela comprend notamment les données relatives à l'expéditeur et à l'authentification, les en-têtes, les URL, le corps du message, la structure HTML, les classifications statistiques et les requêtes externes. L'objectif n'est pas de déterminer la véracité d'un e-mail, mais d'évaluer de manière transparente le risque lié à sa livraison. Rspamd Il regroupe également de nombreux modules de contrôle et peut synthétiser les résultats pour en faire une base de décision.
Plusieurs étapes doivent être dissociées : le MTA accepte d'abord un message SMTP ou le rejette pendant la transmission. Le filtre calcule ensuite, ou pendant le traitement, un score. Un marquage vient par exemple compléter l'en-tête ou, en vertu de règles en aval, déplace le message vers un dossier de courrier indésirable. Un rejet, en revanche, met fin à la réception ; il s'agit donc de la mesure la plus lourde de conséquences et non d'un simple marquage plus strict.
A Faux positif C'est le cas lorsqu'un message légitime est classé à tort comme spam. Cela peut concerner, par exemple, une véritable facture d'un fournisseur dont la pièce jointe au format PDF, la demande de paiement ou le domaine d'expédition inhabituel déclenche plusieurs contrôles. Si le message est simplement marqué, le destinataire peut encore le retrouver ; s’il est rejeté, il n’atteint pas du tout la boîte de réception. Pour la communication professionnelle, cette différence est déterminante.
À l'inverse, un Faux négatif un message de spam qui passe à travers le filtre. On peut citer comme exemple typique une campagne comportant des textes légèrement modifiés, des liens changeants et des en-têtes d'apparence techniquement correcte. De tels messages augmentent le risque de hameçonnage, de logiciels malveillants ou de publicité indésirable, mais cela ne signifie pas pour autant qu'un rejet catégorique soit systématiquement justifié. Un filtre anti-spam optimise en permanence l'équilibre entre ces deux types d'erreurs, et ne vise pas un taux d'erreurs nul.
Les seuils constituent donc un choix opérationnel en matière de gestion des risques. Un seuil bas pour les rejets peut réduire le nombre de spams qui passent à travers les mailles du filet, mais augmente le risque de perte de courriers légitimes. Une valeur plus élevée transfère davantage de responsabilité vers le marquage, la mise en quarantaine et la vérification par l’utilisateur. Il est judicieux d’adopter une stratégie progressive : d’abord le marquage et la surveillance, puis la liste grise ou des mesures plus strictes uniquement lorsque les journaux, les retours d’expérience et le trafic de messagerie interne justifient cette décision.
SpamAssassin : règles, scores et modèle de fonctionnement
SpamAssassin Il s'agit d'un filtre extensible, basé sur des règles et des points. Il analyse notamment les en-têtes, le corps du message, le code HTML et les URL ; il s'appuie également sur des méthodes statistiques, des requêtes réseau et des plugins pour des fonctionnalités telles que Bayes, SPF, DKIM ou DMARC. Chaque correspondance apporte des points au résultat. La somme de ces points donne un score qui peut être comparé à un seuil configuré.
Les personnalisations sont généralement effectuées dans .cf-fichiers. Cela permet notamment de définir des règles relatives à l'en-tête, au corps et à l'URI avec des scores spécifiques. Ce modèle est particulièrement transparent lorsqu'une équipe doit comprendre pourquoi une règle donnée s'est déclenchée. Parallèlement, le nombre d’exceptions, de jeux de règles locaux et d’évaluations différentes entraîne une augmentation de la charge de maintenance : chaque règle nécessite une justification métier, un impact documenté et un contrôle régulier.
En fonctionnement continu du serveur, le service prend généralement spamd réceptionne les ordres de contrôle, tandis que le client léger spamc lui transmet les messages. Cette séparation évite d'avoir à lancer le programme dans son intégralité à chaque message et est prévue pour les vérifications récurrentes. Le service peut également intégrer des configurations SQL ou LDAP ainsi que des paramètres spécifiques à l'utilisateur.
Cela concerne les environnements d'hébergement : un domaine peut nécessiter des listes blanches différentes, tandis que certaines boîtes mail ont leurs propres préférences ou niveaux d'apprentissage. De telles structures, qui se sont développées au fil du temps, ne constituent pas un défaut technique, mais elles compliquent les échanges. Avant toute migration, il convient donc de déterminer clairement quelles règles sont réellement essentielles à l'activité, lesquelles ont simplement été reprises pour des raisons historiques et quelles tâches sont déjà prises en charge par le MTA ou un autre service.
Une installation SpamAssassin bien entretenue ne doit pas nécessairement être remplacée uniquement en raison de son ancienneté. Si les règles sont claires, si l'intégration fonctionne de manière stable et si la charge administrative est adaptée au volume de courrier, une maintenance ciblée peut s'avérer plus judicieuse qu'une migration. À l’inverse, une forte proportion de règles spéciales difficiles à maintenir ne justifie pas une copie aveugle : c’est une raison de stock normal à nettoyer de manière critique, quel que soit le filtre choisi par la suite.
Rspamd : workers, icônes et actions
Rspamd fonctionne selon un modèle maître-esclave. Le maître gère les processus et la configuration, tandis que les esclaves standard analysent les messages. Un « proxy-worker » peut, entre autres, recevoir des requêtes Milter et les distribuer aux « scanners ». Le « controller » fournit des fonctions d'administration et une interface web, mais ne doit pas être exposé sans protection sur le réseau public. Ces rôles permettent de séparer plus clairement le trafic de messagerie, le traitement et l'administration.
Les entrées et sorties non bloquantes constituent un élément important de l'architecture. Les requêtes DNS, Redis ou HTTP peuvent être effectuées de manière asynchrone. Si une vérification attend une réponse externe, cela ne doit pas nécessairement interrompre les autres analyses effectuées par le même worker. Il n’en découle toutefois aucune garantie générale de performance : les résultats réels dépendent toujours de l’ensemble des règles, du matériel, des latences DNS, de Redis, de la connexion MTA et de la composition réelle des messages.
Créer des contrôles dans Rspamd Symboles avec des évaluations et des informations complémentaires. Le filtre les synthétise en un score global et peut proposer une action, par exemple add header, greylist ou reject. Cette action ne constitue pas une décision de distribution automatique : ce sont la configuration et l'intégration concrète dans Postfix, Exim ou Sendmail qui déterminent si et comment le MTA l'applique.
C'est précisément pour cette raison que les seuils existants de SpamAssassin ne doivent pas être repris tels quels. Un score reflète à chaque fois l'interaction entre les règles activées, leur pondération et les sources de données disponibles. Même des contrôles portant le même nom peuvent être pondérés différemment, agrégés différemment ou exécutés à des moments différents dans les deux systèmes. Une comparaison directe de required_score L'utilisation d'un seuil Rspamd serait trompeuse d'un point de vue technique.
Pour l'entreprise, la séparation entre l'évaluation et la mise en œuvre constitue un avantage : tu peux dans un premier temps observer les publications de symboles et les actions proposées sans les rejeter d'emblée. Ce n'est qu'à partir de tes propres messages légitimes, des campagnes identifiées et des retours d'expérience qu'il est possible de déterminer quelles Seuils d'intervention sont justifiables. Ainsi, un paramètre technique par défaut devient une règle de distribution vérifiable, plutôt qu'une limite prétendument objective pour le spam.
Comparaison pour la gestion quotidienne des e-mails
Les différences entre SpamAssassin et Rspamd résident moins dans une règle de détection particulière que dans leur modèle de fonctionnement. Tous deux évaluent les e-mails à partir de nombreux signaux, mais leurs approches en matière de configuration, d'intégration et de fonctionnement distribué diffèrent. Le comparatif suivant présente ces points à titre de base de planification ; il ne remplace en aucun cas une analyse de votre propre trafic de messagerie.
| Critère | SpamAssassin | Rspamd | Conséquences pour l'exploitation |
|---|---|---|---|
| Architecture | Service spamd avec le client spamc | Modèle maître-esclave avec des esclaves normaux et des esclaves proxy | Cela a une incidence sur le traitement en parallèle et l'intégration dans le flux de messagerie. |
| Modèle de configuration | .Fichiers .cf, plugins et, en option, configuration SQL ou LDAP | Configuration modulaire ; les adaptations locales viennent compléter les paramètres par défaut | Les règles existantes ne peuvent pas être transférées sans vérification préalable. |
| Connexion MTA | Transmission généralement vers spamd | Milter pour Postfix et Sendmail ; Exim via spamd_address | L'interface appropriée dépend du MTA utilisé. |
| modèle de régulation | Règles avec des scores numériques pour les en-têtes, le corps et les URI | Symboles, score global et actions suggérées | Les seuils et les scores ne sont pas comparables d'un produit à l'autre. |
| Fonctions d'apprentissage | Bayes et d'autres plugins disponibles | Bayes, classification neuronale et autres modules | Les processus d'apprentissage nécessitent des retours d'information vérifiés plutôt qu'un auto-entraînement à l'aveugle. |
| Besoin de mémoire | En fonction des fonctions activées et de la configuration | Redis est prévu pour plusieurs modules de production avec état | Les infrastructures supplémentaires doivent être surveillées et sécurisées. |
| Interface web | Pas de rôle de contrôleur équivalent dans le modèle de base | Contrôleur avec interface Web et API d'administration | L'accès administratif nécessite un contrôle d'accès restrictif. |
| Mise à l'échelle | Fonctionnement orienté services ; la configuration peut être centralisée | Le proxy peut répartir les requêtes entre les scanners | Une architecture distribuée offre des possibilités, mais crée également de nouvelles dépendances. |
| coût de la migration | Les règles et les données existantes sont déjà en place | Reprise partielle des règles, réentraînement des données bayésiennes | Un fonctionnement en parallèle réduit le risque de prendre des décisions erronées sans s'en rendre compte. |
Pour un petit serveur autonome, une installation SpamAssassin bien entretenue ne constitue donc pas une urgence technique. Si les règles définies sont compréhensibles, que le service fonctionne de manière stable et que les erreurs de classification sont corrigées, le maintien de cette installation peut représenter un effort de modification moindre. Une refonte avec Rspamd reste néanmoins envisageable si son intégration à Milter et ses modules centralisés s'adaptent mieux à l'environnement prévu.
Dans les environnements d'hébergement comportant plusieurs scanners, la Mise à l'échelle plus important que le simple nombre de règles installées. Le proxy-worker de Rspamds peut transférer les requêtes Milter à d’autres workers ; les requêtes externes asynchrones ne doivent pas pour autant bloquer l’ensemble du worker. Cela n’implique toutefois aucune garantie générale de performances : les latences DNS, les règles, le matériel et la composition des messages déterminent le débit réel.
Intégration MTA, Redis et modules basés sur l'état
L'intégration technique détermine à quel endroit un filtre anti-spam pour les e-mails renvoie son évaluation à l'agent de transfert de courrier. Rspamd peut être connecté à Postfix et Sendmail via Milter. Exim utilise pour cela son intégration via spamd_address. Le filtre fournit un résultat, mais c'est toujours le MTA et la configuration choisie qui déterminent si un message sera marqué, retardé ou rejeté.
Toutes les vérifications ne nécessitent pas un état commun. Les protocoles SPF, DKIM et DMARC analysent les informations d’authentification ; les listes basées sur le DNS et les expressions régulières vérifient d’autres caractéristiques d’un message individuel. Même si ces vérifications peuvent nécessiter des réponses DNS externes, elles ne génèrent pas automatiquement d'historique d'apprentissage. Leur pertinence dépend, entre autres, du bon fonctionnement du DNS et d'une pondération appropriée au sein de l'ensemble des règles.
Travailler autrement modules basés sur l'état. La classification bayésienne enregistre les caractéristiques apprises, la liste grise doit reconnaître les tentatives de livraison antérieures, et les limites de débit nécessitent des compteurs sur plusieurs connexions. Dans l’architecture documentée, Rspamd prévoit l’utilisation de Redis pour la classification bayésienne, la classification neuronale, le greylisting et d’autres états. Cela permet à plusieurs instances d’accéder à des informations communes.
Redis n'est donc ni un élément interchangeable, ni une condition préalable à chaque contrôle Rspamd. En l'absence de mémoire accessible, les modules statiques peuvent continuer à fonctionner, tandis que les fonctions d'apprentissage et de réputation sont limitées ou indisponibles. Les opérateurs doivent donc définir, avant la mise en production, la disponibilité, la connexion réseau, la protection des accès, la sauvegarde et le comportement à adopter en cas de panne de Redis.
D'un point de vue pratique, il est judicieux de séparer les responsabilités : le MTA accepte les connexions SMTP et applique la décision de filtrage, Rspamd évalue les messages, tandis que Redis gère les états requis. Cette répartition facilite le dépannage, mais augmente le nombre de services à surveiller. Une dépendance lente ou inaccessible ne doit pas être compensée par des rejets irréfléchis.
Transférer les règles et les données d'apprentissage de manière contrôlée
Une migration commence par un état des lieux, et non par la copie de tous les fichiers. Les règles personnalisées méritent tout particulièrement d'être examinées : elles peuvent refléter des exigences métier, mais aussi contenir des exceptions obsolètes. Rspamd fournit un module SpamAssassin qui ne traite qu'une partie des règles. La similitude technique d’une règle ne garantit donc pas qu’elle produise le même effet.
| Module SpamAssassin | Équivalent possible de Rspamd | Reprise | Contrôle nécessaire |
|---|---|---|---|
| spamd et spamc | Worker, Proxy-Worker et rspamc | Pas de reprise directe | Redéfinir l'interface MTA, le délai d'expiration et le comportement en cas d'erreur. |
| Règles personnalisées pour les éléments « body », « header » et « uri » | Module SpamAssassin ou règles Rspamd natives | Partiellement possible | Vérifier la syntaxe prise en charge et les symboles déclenchés à l'aide de messages de test. |
| AWL | Fonctions liées à la réputation et à l'état | Pas de migration à l'identique | Réévaluer l'objectif et les répercussions sur les expéditeurs connus. |
| Base de données de Bayes | Apprentissage bayésien de Rspamd | Impossible à importer | Réentraîner le modèle à l'aide de corpus de messages légitimes et de spam validés. |
Ce module permet notamment de body-, rawbody-, header-, meta- et uri- Traiter les règles. En revanche, les plugins spécifiques au réseau et au HTML ne sont pas entièrement pris en charge. Le chargement sans vérification de jeux de règles tiers volumineux peut compliquer la configuration et alourdir le traitement. Il est préférable de n'intégrer que les règles propres dont le besoin est avéré et de privilégier les modules natifs.
Cela nécessite une attention particulière Apprentissage bayésien. Selon la documentation de Rspamd, les bases de données Bayes de SpamAssassin ne peuvent pas être importées. Rspamd a donc besoin de nouveaux corpus validés, composés de messages souhaités et de spams. Les factures, newsletters ou campagnes mal classées faussent la classification et peuvent aggraver les erreurs de classification ultérieures.
AWL ne doit pas non plus être considéré comme un transfert de fichiers. L'historique des expéditeurs et l'évaluation actuelle de la réputation poursuivent certes des objectifs similaires, mais peuvent s'appuyer sur des sources de données et des pondérations différentes. Il convient donc de commencer par documenter l’effet escompté d’une exception ou d’une règle de confiance existante. Ce n’est qu’ensuite qu’il sera possible de déterminer s’il est plus approprié d’utiliser une fonction native de Rspamd ou de définir une règle personnalisée ciblée.
Mettre en place Rspamd en toute sécurité en mode parallèle
Une migration réussie ne commence pas par le remplacement du filtre actuel, mais par un état des lieux. Documentez la connexion MTA, les règles SpamAssassin, les exceptions spécifiques aux utilisateurs, les dépendances DNS, les expéditeurs autorisés et le traitement actuel des messages suspects. Déterminez également quels indicateurs seront importants par la suite : par exemple, les e-mails professionnels marqués à tort comme spam, les campagnes qui ont échappé au filtrage et la charge de travail manuelle.
Commencez par installer Rspamd séparément du chemin de messagerie principal et intégrez-le de manière à ce que son évaluation soit enregistrée, sans pour autant modifier la distribution des messages. Le « Shadow Mode » (mode fantôme) documenté permet précisément cette observation : Rspamd analyse les messages sans appliquer les actions qu’il propose. Ainsi, SpamAssassin reste le seul décideur actif pendant la phase de comparaison.
Ne tiens pas seulement compte du score total, mais surtout des éléments déclenchés Symboles et l'action qui en découle. Une valeur élevée peut résulter d’erreurs d’authentification, de caractéristiques d’URL, de données de réputation ou de règles locales ; ces causes nécessitent des corrections différentes. Vérifie donc, pour chaque message suspect, l’en-tête, le groupe de destinataires et l’action proposée par le filtre avant de modifier les scores ou les modules.
Une comparaison pertinente inclut de manière ciblée des cas limites souhaités et indésirables. Une facture légitime d'un fournisseur connu peut, par exemple, contenir un fichier PDF et un lien de suivi externe. Une campagne de spam variée modifie en revanche en permanence l'objet, les blocs de texte et l'expéditeur, tout en conservant des URL ou des caractéristiques structurelles typiques. Ces deux types de messages permettent de déterminer si certains symboles contribuent de manière pertinente à la détection ou si une règle s'applique de manière trop générale.
Passeport Valeurs seuils ne doit être activée que lorsque l'on dispose d'un nombre suffisant d'exemples vérifiables. L'échelle de score de Rspamd n'est pas comparable à une valeur SpamAssassin existante ; une reprise directe peut donc déclencher des actions inappropriées. Déterminez séparément à partir de quel moment il faut simplement compléter les en-têtes, quand il faut mettre temporairement un message sur liste grise et dans quelles conditions il doit être rejeté. L’intégration MTA détermine alors si et comment une action est effectivement appliquée.
Après une phase d'observation planifiée, la bascule s'effectue de manière contrôlée : Rspamd devient le filtre actif, tandis que SpamAssassin reste installé et configurable, mais n'intervient plus dans le flux de messagerie. Cette période de transition doit définir les responsabilités, une méthode documentée de retour en arrière et les critères d'interruption. Une configuration de pare-feu clairement délimitée constitue un atout supplémentaire ; l'article explique les principes de base d'une migration progressive des règles. Netfilter vs. nftables.
Exploitation, journalisation et dépannage systématique
En cas de rejet inattendu, le diagnostic commence par le message concret et sa chaîne de traitement, et non par un assouplissement général du seuil de filtrage. Vérifiez le protocole MTA, le résultat de Rspamd, les symboles déclenchés, le score et l'action proposée. Ce n'est qu'après cette analyse que l'on peut déterminer si le rejet a été causé, par exemple, par une règle locale, une vérification basée sur le DNS ou l'application des règles par le MTA.
Le spam qui a réussi à passer nécessite une analyse inversée. Vérifie si le message est bien parvenu à Rspamd, quels symboles manquent et si une action configurée n'a pas été déclenchée en raison du score. Si les résultats DNS attendus font défaut, examine les résolveurs, l'accessibilité et les temps de réponse avant de rédiger de nouvelles règles de contenu. Toutes les campagnes ne peuvent pas être correctement ciblées par un seuil unique.
Une panne de Redis doit être traitée séparément, car elle peut affecter les fonctions basées sur l'état. Vérifiez la connexion entre le filtre et la mémoire, les journaux du service Redis, puis identifiez les modules qui dépendent de cet état. Les contrôles statiques peuvent continuer à fournir des résultats, mais l'apprentissage bayésien, la liste grise ou d'autres évaluations dépendantes de l'état nécessitent un système de stockage de données opérationnel.
Si une règle attendue ne se déclenche pas, vérifiez d'abord son emplacement de chargement réel, sa syntaxe et le format du message sur lequel elle est censée s'appliquer. Les vérifications des en-têtes, du texte brut, du HTML et des URL portent sur des données différentes. Avec SpamAssassin, les fichiers de règles peuvent être vérifiés à l'aide d'un contrôle syntaxique avant leur mise en service ; la commande suivante vérifie la configuration et n'affecte en rien la distribution effective du courrier.
Pour les dysfonctionnements récurrents, regroupez dans une vue unique les horodatages, le comportement de la file d'attente, les requêtes DNS et les erreurs de réponse. Cela permet de déterminer si un retard de livraison provient du MTA, d'une requête externe ou du processus de filtrage. Pour une télémétrie Linux plus approfondie et la surveillance des systèmes en cours d'exécution, l'article complémentaire propose bpftool pour l'analyse moderne du noyau principes techniques.
Ne modifiez pas de manière impulsive les scores globaux ni les ensembles de règles à grande échelle à la suite d'un incident isolé. Veillez plutôt à conserver le message concerné dans le respect de la protection des données, comparez-le à des cas similaires et documentez la cause ainsi que la modification apportée. Ceci Analyse des erreurs permet d'apporter des corrections justifiables et réduit le risque qu'une règle d'exception entraîne par la suite un traitement erroné d'un grand nombre d'e-mails légitimes ou indésirables.
Prendre une décision en fonction du profil du serveur
Il est tout à fait plausible de continuer à utiliser SpamAssassin de manière ciblée si le serveur de messagerie existant est géré de manière fiable, avec ses propres règles, ses paramètres par utilisateur et ses procédures opérationnelles. Le système est extensible sur la base de règles et de points et prend en charge des plugins ainsi que divers chemins de configuration et de stockage. Changer de système uniquement en raison de l'ancienneté d'une installation n'apporte aucun avantage technique s'il n'existe aucun problème concret de fonctionnement.
Rspamd s'impose comme un choix évident pour une refonte lorsque l'intégration de Milter, les contrôles d'authentification modernes, la gestion centralisée et les modules basés sur l'état sont planifiés ensemble dès le départ. Son architecture comprend des rôles de « workers » pour le traitement, les connexions proxy et la gestion ; parallèlement, le DNS et, le cas échéant, Redis doivent être exploités de manière fiable en tant que dépendances opérationnelles. Il s'agit d'un choix architectural, et non d'une garantie générale de performances.
Pour les environnements d'hébergement bien établis présentant de nombreux cas particuliers, le Fonctionnement en parallèle C'est généralement l'option la plus fiable. Elle permet d'identifier les règles SpamAssassin propres à l'entreprise qui restent nécessaires, de vérifier si les indicateurs Rspamd reflètent bien les causes attendues et de déterminer quels groupes de destinataires sont particulièrement sensibles aux erreurs de classification. Ce n’est que sur cette base qu’il est possible de décider d’une migration complète ou du maintien délibéré du système existant.
Le choix dépend donc moins du nombre de boîtes aux lettres que de la capacité de maintenance et des dépendances. Quiconque est en mesure d’assurer en permanence la gestion de Redis, du résolveur DNS, de l’analyse des protocoles et des mises à jour peut exploiter Rspamd de manière cohérente, y compris ses fonctions d’apprentissage et basées sur l’état. En l’absence de ces ressources, un parc allégé, bien documenté et doté de règles claires peut représenter le risque opérationnel le plus faible.
Quel que soit le produit, veillez à ne pas exposer le contrôleur Rspamd sur le réseau sans protection. La documentation recommande une connexion locale ou une protection par pare-feu ; en cas d'accès à distance, une protection de l'accès et un hachage du mot de passe sont obligatoires. De plus, ne reprenez pas sans vérification les règles de tiers ni les scores historiques. Des mesures isolées ou des campagnes particulièrement marquantes ne constituent pas une base suffisante pour une politique de filtrage globale.
La bonne décision est donc celle qui évaluation des risques: La protection contre les messages indésirables s'oppose aux conséquences de la perte d'e-mails légitimes. Définissez pour chaque action qui en est responsable, comment elle est vérifiée et comment revenir à l'état précédent. Ainsi, le filtre anti-spam reste un élément maîtrisable du fonctionnement de la messagerie, plutôt qu'une instance automatique difficile à comprendre.
Sources et état des connaissances
État de la recherche :
Période couverte par la recherche : documentation SpamAssassin pour la branche stable 4.0.x ; Rspamd selon les fonctionnalités stables documentées, avec la version 4.2.2 comme publication GitHub répertoriée le 20 octobre 2026. Les branches de développement et les commits non documentés ne sont pas pris en compte.
https://docs.rspamd.com/tutorials/migrate_sa/
https://docs.rspamd.com/getting-started/
https://spamassassin.apache.org/full/4.0.x/doc/spamassassin.html
https://spamassassin.apache.org/full/4.0.x/doc/spamd.html
https://docs.rspamd.com/developers/architecture/
https://docs.rspamd.com/getting-started/understanding-rspamd/
https://docs.rspamd.com/
https://spamassassin.apache.org/full/4.0.x/doc/Mail_SpamAssassin_Conf.html




