Il passaggio a Rspamd non è automaticamente vantaggioso. SpamAssassin può continuare a essere una soluzione adeguata in presenza di regole stabili e di un carico di manutenzione gestibile; Rspamd è particolarmente interessante per le nuove implementazioni, l’integrazione con Milter e gli ambienti scalabili in modo controllato. Ciò che conta non sono i punteggi predefiniti, bensì gli errori di classificazione, le dipendenze e un funzionamento parallelo sicuro. Rspamd valuta i messaggi tramite simboli e suggerisce azioni la cui esecuzione viene determinata solo dall’integrazione con l’MTA.
Obiettivi dei filtri antispam ed errori inevitabili
Un filtro antispam per e-mail valuta i messaggi nel flusso di posta in base a caratteristiche tecniche e di contenuto. A seconda del prodotto, queste includono, ad esempio, i dati del mittente e di autenticazione, le intestazioni, gli URL, il testo del messaggio, la struttura HTML, le classificazioni statistiche e le query esterne. L’obiettivo non è quello di accertare la veridicità di un’e-mail, bensì di classificarne il rischio di consegna in modo trasparente. Rspamd A tal fine, integra anch’esso numerosi moduli di verifica ed è in grado di riunire i risultati in un documento di supporto decisionale.
In questo contesto, diverse fasi devono rimanere distinte: l’MTA accetta inizialmente un messaggio SMTP oppure lo respinge durante la trasmissione. Il filtro calcola poi un punteggio, durante o dopo l’integrazione. Un contrassegno, ad esempio, integra l’intestazione oppure, in base a regole a valle, sposta il messaggio in una cartella “spam”. Un rifiuto, invece, interrompe l’accettazione; si tratta quindi della misura con le conseguenze più gravi e non semplicemente di un’indicazione più marcata.
A Falso positivo Si verifica quando un messaggio legittimo viene erroneamente classificato come spam. Ciò può riguardare, ad esempio, una fattura autentica di un fornitore, il cui allegato PDF, la richiesta di pagamento o un dominio di invio insolito attivano diversi controlli. Se viene semplicemente contrassegnato, il destinatario può ancora trovarlo; se viene respinto, non raggiunge affatto la casella di posta. Per la comunicazione aziendale questa differenza è determinante.
Al contrario, un Falso negativo un messaggio di spam che supera il filtro. Un esempio tipico è una campagna con testi leggermente modificati, link variabili e intestazioni che sembrano tecnicamente corrette. Messaggi di questo tipo aumentano il rischio di phishing, malware o pubblicità indesiderata, ma non implicano automaticamente che ogni rifiuto categorico sia giustificato. Un filtro antispam per le e-mail cerca sempre di trovare un equilibrio tra questi due tipi di errore, non di raggiungere una percentuale di accuratezza perfetta.
I valori di soglia rappresentano quindi una scelta aziendale in materia di rischio. Un valore basso per i messaggi rifiutati può ridurre lo spam che riesce a passare, ma aumenta il rischio di perdere messaggi legittimi. Un valore più alto trasferisce maggiore responsabilità alla contrassegnazione, alla quarantena e alla verifica da parte dell’utente. È consigliabile adottare una strategia graduale: prima la contrassegnazione e il monitoraggio, poi il greylisting o misure più severe solo nei casi in cui i log, i feedback e il proprio traffico di posta giustifichino tale decisione.
SpamAssassin: regole, punteggi e modello operativo
SpamAssassin È un filtro espandibile, basato su regole e punteggi. Analizza, tra l’altro, intestazioni, corpo del testo, codice HTML e URL; sono inoltre disponibili metodi statistici, interrogazioni di rete e plugin per funzioni quali Bayes, SPF, DKIM o DMARC. I singoli risultati positivi contribuiscono al punteggio finale. La somma di questi punti genera un punteggio che può essere confrontato con un valore limite configurato.
Le personalizzazioni effettuate dall'utente vengono solitamente apportate in .cf-file. Ciò consente, ad esempio, di definire regole relative a header, body e URI con punteggi personalizzati. Questo modello risulta particolarmente trasparente quando un team deve comprendere il motivo per cui una determinata regola è stata attivata. Allo stesso tempo, con l’aumentare delle eccezioni, dei pacchetti di regole locali e delle diverse valutazioni, cresce anche l’onere di manutenzione: ogni regola richiede una motivazione tecnica, un effetto documentato e un controllo regolare.
Nel funzionamento continuo del server, il servizio solitamente spamd Accetta gli ordini di controllo, mentre il client leggero spamc gli trasmette i messaggi. Questa separazione evita l'onere di un avvio completo del programma per ogni singolo messaggio ed è pensata per i controlli ricorrenti. Il servizio può inoltre integrare configurazioni SQL o LDAP, nonché impostazioni specifiche per utente.
Questo è rilevante per gli ambienti di hosting: un dominio può richiedere whitelist diverse, mentre le singole caselle di posta possono avere preferenze o livelli di apprendimento propri. Tali strutture consolidate non rappresentano un difetto tecnico, ma rendono più difficile la migrazione. Prima di procedere a una migrazione, occorre quindi chiarire quali regole siano effettivamente fondamentali per l’attività, quali siano state semplicemente ereditate dal passato e quali compiti siano già svolti dall’MTA o da un altro servizio.
Un’installazione ben curata di SpamAssassin non deve essere sostituita solo a causa della sua età. Se le regole sono comprensibili, l’integrazione funziona in modo stabile e l’onere amministrativo è adeguato al volume di posta, una manutenzione mirata può rivelarsi più sensata di una migrazione. Al contrario, un’elevata percentuale di regole speciali di difficile manutenzione non è un argomento a favore di una copia cieca: è un motivo per Stock normale da pulire in modo accurato, indipendentemente dal filtro che verrà scelto in seguito.
Rspamd: worker, icone e azioni
Rspamd funziona con un modello master-worker. Il master gestisce i processi e la configurazione, mentre i normali worker controllano i messaggi. Un proxy-worker può, tra le altre cose, ricevere richieste Milter e distribuirle agli scanner. Il controller fornisce funzioni di amministrazione e un'interfaccia web, ma non deve essere esposto senza protezione alla rete pubblica. Questi ruoli separano in modo più netto il traffico di posta, l'elaborazione e l'amministrazione.
Un aspetto importante per l'architettura è l'input e l'output non bloccanti. Le richieste DNS, Redis o HTTP possono essere eseguite in modo asincrono. Se un controllo è in attesa di una risposta esterna, ciò non comporta necessariamente l’interruzione di altre scansioni dello stesso worker. Ciò non implica tuttavia una garanzia generale di prestazioni: i risultati effettivi continuano a dipendere dall’insieme delle regole, dall’hardware, dalle latenze DNS, da Redis, dalla connessione MTA e dall’effettivo mix di messaggi.
Generazione di test in Rspamd Simboli con valutazioni e informazioni aggiuntive. Il filtro le sintetizza in un punteggio complessivo e può suggerire un’azione, ad esempio add header, greylist oppure reject. Questa impostazione non comporta una decisione automatica sulla consegna: sono la configurazione e l'integrazione concreta in Postfix, Exim o Sendmail a determinare se e in che modo l'MTA la applichi.
Proprio per questo motivo, i valori limite predefiniti di SpamAssassin non devono essere adottati tali e quali. Ogni punteggio riflette l’interazione tra le regole attivate, la loro ponderazione e le fonti di dati disponibili. Anche i controlli con lo stesso nome possono essere ponderati in modo diverso nei due sistemi, aggregati in modo diverso o eseguiti in momenti diversi. Un confronto diretto tra required_score utilizzare una soglia Rspamd sarebbe tecnicamente fuorviante.
Dal punto di vista operativo, la separazione tra valutazione e applicazione rappresenta un vantaggio: puoi innanzitutto osservare le pubblicazioni dei simboli e le azioni proposte senza rifiutarle immediatamente. Solo sulla base dei propri messaggi legittimi, delle campagne individuate e dei riscontri è possibile stabilire quali Soglie di intervento sono giustificabili. In questo modo, un’impostazione tecnica predefinita si trasforma in una linea guida verificabile per la consegna, anziché in un limite apparentemente oggettivo per lo spam.
Confronto per la gestione quotidiana della posta elettronica
Le differenze tra SpamAssassin e Rspamd non risiedono tanto in una singola regola di rilevamento quanto nel modello operativo. Entrambi valutano le e-mail sulla base di numerosi segnali, ma le modalità di configurazione, integrazione e funzionamento distribuito sono diverse. Il seguente confronto illustra questi aspetti come base di pianificazione; non sostituisce in alcun modo un'analisi del proprio traffico di posta elettronica.
| Criterio | SpamAssassin | Rspamd | Importanza per l'azienda |
|---|---|---|---|
| Architettura | Servizio spamd con client spamc | Modello Master-Worker con worker normali e proxy | Influisce sulla parallelizzazione e sull'integrazione nel flusso di posta. |
| Modello di configurazione | .File .cf, plugin e, facoltativamente, configurazione SQL o LDAP | Configurazione basata su moduli; le personalizzazioni locali integrano le impostazioni predefinite | La gestione delle regole esistenti non è trasferibile senza una verifica. |
| Collegamento MTA | Invio tipicamente a spamd | Milter per Postfix e Sendmail; Exim tramite spamd_address | L'interfaccia adeguata dipende dall'MTA utilizzato. |
| Modello normativo | Regole con punteggi numerici per intestazioni, corpo e URI | Simboli, punteggio totale e azioni suggerite | I valori soglia e i punteggi non sono comparabili tra i diversi prodotti. |
| Funzioni didattiche | Bayes e altri plugin disponibili | Bayes, classificazione neurale e altri moduli | I processi di apprendimento richiedono un feedback verificato anziché un auto-addestramento alla cieca. |
| Requisiti di memoria | A seconda delle funzioni attivate e della configurazione | Redis è destinato a diversi moduli produttivi con stato | Le infrastrutture aggiuntive devono essere monitorate e protette. |
| Interfaccia web | Nel modello base non è presente un ruolo di controller equivalente | Controller con interfaccia web e API di gestione | L'accesso amministrativo richiede un controllo degli accessi rigoroso. |
| Scala | Funzionamento orientato ai servizi; la configurazione può essere centralizzata | Il proxy può distribuire le richieste agli scanner | L'architettura distribuita offre nuove opportunità, ma crea anche ulteriori dipendenze. |
| Costi di migrazione | Le regole e i dati esistenti sono già stati definiti | Applicazione parziale delle regole, riaddestramento dei dati di Bayes | Il funzionamento in parallelo riduce il rischio di decisioni errate non individuate. |
Per un piccolo server singolo, un’installazione ben gestita di SpamAssassin non rappresenta quindi un’emergenza tecnica. Se le regole personalizzate sono comprensibili, il servizio funziona in modo stabile e gli errori di classificazione vengono corretti, mantenerla può significare un minore sforzo di modifica. Una nuova configurazione con Rspamd rimane comunque una valida opzione, qualora la sua integrazione con Milter e i moduli raggruppati a livello centrale si adattino meglio all’ambiente previsto.
Negli ambienti di hosting con più scanner, la Scala più importante del semplice numero di regole installate. Il proxy worker di Rspamd può inoltrare le richieste Milter ad altri worker; le query esterne asincrone non devono bloccare l’intero worker. Ciò non implica tuttavia una garanzia generale di prestazioni: le latenze DNS, le regole, l’hardware e il mix di messaggi determinano la velocità effettiva.
Integrazione MTA, Redis e moduli basati sullo stato
L'integrazione tecnica determina in quale punto un filtro antispam per le e-mail restituisce la propria valutazione al Mail Transfer Agent. Rspamd può essere collegato a Postfix e Sendmail tramite Milter. Exim utilizza a tal fine la propria integrazione tramite spamd_address. Il filtro fornisce un risultato, ma sono comunque l’MTA e la configurazione selezionata a decidere se un messaggio debba essere contrassegnato, ritardato o respinto.
Non tutti i controlli richiedono uno stato comune. SPF, DKIM e DMARC valutano le informazioni di autenticazione; gli elenchi basati su DNS e le espressioni regolari verificano ulteriori caratteristiche di un singolo messaggio. Sebbene tali controlli possano richiedere risposte DNS esterne, non generano automaticamente una cronologia di apprendimento. La loro attendibilità dipende, tra l’altro, dal corretto funzionamento del DNS e da un’adeguata ponderazione nell’ambito dell’intero insieme di regole.
Lavorare in modo diverso moduli basati sullo stato. La classificazione bayesiana memorizza le caratteristiche apprese, il greylisting deve riconoscere i precedenti tentativi di consegna e i limiti di frequenza richiedono contatori che coprano più connessioni. Rspamd prevede l’uso di Redis nell’architettura documentata per la classificazione bayesiana, la classificazione neurale, il greylisting e altri stati. Ciò consente a più istanze di accedere a informazioni condivise.
Redis non è quindi né un dettaglio trascurabile né un prerequisito per ogni singolo controllo di Rspamd. In assenza di memoria disponibile, i moduli statici possono continuare a funzionare, mentre le funzioni di apprendimento e di reputazione risultano limitate o non funzionano. Gli amministratori devono pertanto definire, prima della messa in produzione, la disponibilità, la connessione di rete, la protezione degli accessi, il backup e il comportamento da adottare in caso di guasto di Redis.
In pratica, è opportuno separare le responsabilità: l’MTA accetta le connessioni SMTP e applica la decisione di filtraggio, Rspamd valuta i messaggi, Redis mantiene gli stati necessari. Questa suddivisione facilita la ricerca degli errori, ma aumenta il numero dei servizi da monitorare. Una dipendenza lenta o non raggiungibile non dovrebbe essere compensata da rifiuti avventati.
Trasferire le regole e i dati di apprendimento in modo controllato
Una migrazione inizia con un'analisi della situazione attuale, non con la copia di tutti i file. Le regole personalizzate meritano particolare attenzione: possono riflettere le esigenze aziendali, ma possono anche contenere eccezioni obsolete. Rspamd mette a disposizione un modulo di SpamAssassin che elabora solo una parte delle regole. La somiglianza tecnica di una regola non garantisce quindi che essa produca lo stesso effetto.
| Modulo SpamAssassin | Possibile corrispondenza con Rspamd | Acquisizione | Verifica necessaria |
|---|---|---|---|
| spamd e spamc | Worker, Proxy-Worker e rspamc | Nessun trasferimento diretto | Ridefinire l'interfaccia MTA, il timeout e il comportamento in caso di errore. |
| Regole personalizzate per body, header e uri | Modulo SpamAssassin o regole native di Rspamd | Parzialmente possibile | Verificare la sintassi supportata e i simboli attivati con messaggi di prova. |
| AWL | Funzioni relative alla reputazione e allo stato | Nessuna migrazione 1:1 | Rivalutare l'obiettivo e le ripercussioni sui mittenti noti. |
| Database di Bayes | Addestramento Bayesiano di Rspamd | Non importabile | Riapprendimento con corpora verificati di ham e spam. |
Il modulo è in grado, tra l'altro, di body-, rawbody-, header-, meta- e uri-Elaborazione delle regole. I plugin specifici per la rete e per l'HTML, invece, non sono completamente supportati. Caricare senza verifica set di regole esterni di grandi dimensioni può complicare la configurazione e appesantire l'elaborazione. È preferibile adottare solo regole proprie di cui si dimostri effettivamente la necessità e privilegiare i moduli nativi.
Ciò richiede particolare attenzione Addestramento bayesiano. Secondo la documentazione di Rspamd, i database Bayes di SpamAssassin non possono essere importati. Per Rspamd sono quindi necessari nuovi corpora verificati, composti da messaggi desiderati e spam. Fatture, newsletter o campagne classificate erroneamente influenzano la classificazione in modo negativo e possono aggravare successive decisioni errate.
Anche AWL non dovrebbe essere trattato come un’acquisizione di file. Sebbene la cronologia dei mittenti precedenti e la valutazione attuale della reputazione perseguano obiettivi affini, possono avvalersi di fonti di dati e ponderazioni diverse. Documentare quindi innanzitutto quale effetto si intende ottenere con un'eccezione o una regola di fiducia esistente. Solo in seguito sarà possibile decidere se sia più appropriata una funzione nativa di Rspamd o una regola personalizzata mirata.
Implementare Rspamd in modo sicuro in modalità parallela
Una migrazione produttiva non inizia con la sostituzione del filtro esistente, ma con un’analisi della situazione attuale. Documenta l’integrazione MTA, le regole di SpamAssassin, le eccezioni relative agli utenti, le dipendenze DNS, i mittenti accettati e l’attuale gestione dei messaggi sospetti. Stabilisci inoltre quali indicatori saranno rilevanti in seguito: ad esempio, le e-mail aziendali contrassegnate erroneamente, le campagne passate inosservate e il carico di lavoro manuale.
Per prima cosa, installa Rspamd separatamente dal percorso di posta principale e configuralo in modo che la sua valutazione venga registrata, ma senza modificare la consegna. La modalità «Shadow Mode», documentata nella documentazione, consente proprio questo tipo di monitoraggio: Rspamd verifica i messaggi senza applicare le azioni proposte. In questo modo, durante la fase di confronto, SpamAssassin rimane l'unico sistema attivo a prendere decisioni.
Non considerare solo il punteggio totale, ma soprattutto quelli attivati Simboli e l'azione che ne deriva. Un valore elevato può derivare da errori di autenticazione, caratteristiche dell’URL, dati sulla reputazione o regole locali; queste cause richiedono correzioni diverse. Verifica quindi, per ogni messaggio sospetto, l’intestazione, il gruppo di destinatari e l’azione suggerita dal filtro prima di modificare i punteggi o i moduli.
Un confronto significativo include casi limite sia desiderati che indesiderati. Una fattura legittima di un fornitore noto può, ad esempio, contenere un file PDF e un link di tracciamento esterno. Una campagna di spam variegata, invece, modifica continuamente l’oggetto, i blocchi di testo e il mittente, pur mantenendo URL tipici o caratteristiche strutturali. Entrambi i tipi di messaggi mostrano se i singoli simboli contribuiscono in modo comprensibile o se una regola è troppo generica.
Giogo Valori di soglia solo quando sono disponibili esempi sufficientemente verificabili. La scala di punteggio di Rspamd non è equiparabile a un valore precedente di SpamAssassin; un’adozione diretta può quindi innescare azioni inappropriate. Decidi separatamente a partire da quando aggiungere solo le intestazioni, quando inserire temporaneamente nella lista grigia e in quali condizioni rifiutare i messaggi. L’integrazione MTA determina se e come un’azione venga effettivamente applicata.
Dopo una fase di monitoraggio pianificata, il passaggio avviene in modo controllato: Rspamd diventa il filtro attivo, mentre SpamAssassin rimane installato e configurabile, ma non interviene più nel flusso di posta. Questo periodo di transizione dovrebbe prevedere la definizione delle responsabilità, una procedura documentata per il ritorno alla configurazione precedente e i criteri per l’interruzione del processo. Inoltre, è utile una configurazione del firewall ben definita; l’articolo illustra le basi per una migrazione graduale delle regole. Netfilter vs. nftables.
Funzionamento, registrazione dei dati e ricerca sistematica degli errori
In caso di rifiuto inaspettato, la diagnosi inizia dal messaggio specifico e dalla sua catena di elaborazione, non con un allentamento generico della soglia di filtraggio. Verifica il log dell’MTA, il risultato di Rspamd, i simboli generati, il punteggio e l’azione suggerita. Solo questa analisi permette di stabilire se il rifiuto sia stato causato, ad esempio, da una regola locale, da un controllo basato sul DNS o dall’applicazione delle regole da parte dell’MTA.
Lo spam che è riuscito a passare richiede un'analisi a ritroso. Verifica se il messaggio è effettivamente arrivato a Rspamd, quali simboli mancano e se un'azione configurata non è stata eseguita a causa del punteggio. Se mancano i risultati DNS previsti, verifica i resolver, l’accessibilità e i tempi di risposta prima di scrivere nuove regole di contenuto. Non tutte le campagne possono essere efficacemente intercettate con un unico valore soglia.
Un guasto di Redis deve essere trattato separatamente, poiché può compromettere le funzioni basate sullo stato. Verifica la connessione del filtro alla memoria, i log del servizio Redis e, successivamente, quali moduli dipendono da tale stato. I controlli statici possono continuare a fornire risultati, ma l’addestramento bayesiano, il greylisting o altre valutazioni dipendenti dallo stato richiedono un sistema di gestione dei dati funzionante.
Se una regola prevista non viene attivata, verifica innanzitutto la sua posizione effettiva nel file, la sintassi e il formato del messaggio su cui dovrebbe operare. I controlli relativi all'intestazione, al testo grezzo, all'HTML e agli URL prendono in esame dati diversi. In SpamAssassin, i file delle regole possono essere verificati con un controllo sintattico prima dell'applicazione; il comando seguente verifica la configurazione e non modifica la consegna effettiva della posta.
Per i malfunzionamenti ricorrenti, conserva in un’unica vista i timestamp, il comportamento della coda, le richieste DNS e gli errori di risposta. In questo modo è possibile distinguere se un ritardo nella consegna è dovuto all’MTA, a una richiesta esterna o al processo di filtraggio. Per ulteriori informazioni sulla telemetria Linux e sul monitoraggio dei sistemi in esecuzione, consulta l’articolo complementare bpftool per l'analisi moderna del kernel Nozioni tecniche di base.
Non modificare d’istinto, a seguito di un singolo episodio, né i punteggi globali né i set di regole di ampia portata. Assicurati invece di archiviare il messaggio in questione nel rispetto della normativa sulla protezione dei dati, confrontalo con casi simili e documenta la causa insieme alla modifica apportata. Questo Analisi degli errori garantisce correzioni tracciabili e riduce il rischio che una regola di eccezione tratti in modo errato, in un secondo momento, grandi quantità di e-mail legittime o indesiderate.
Prendere una decisione in base al profilo del server
Continuare a utilizzare SpamAssassin in modo mirato è plausibile se il server di posta esistente viene gestito in modo affidabile con le proprie regole, le impostazioni per utente e le procedure operative. Il sistema è espandibile sulla base di regole e punti e supporta plugin, nonché diversi percorsi di configurazione e archiviazione. Una sostituzione motivata esclusivamente dall’età di un’installazione non apporta alcun vantaggio tecnico, se non sussiste un problema operativo concreto.
Rspamd è la scelta più ovvia per una nuova implementazione, se l’integrazione con Milter, i moderni controlli di autenticazione, il controllo centralizzato e i moduli basati sullo stato vengono pianificati insieme fin dall’inizio. La sua architettura comprende ruoli di worker per l’elaborazione, connessioni proxy e gestione; allo stesso tempo, il DNS e, se necessario, Redis devono essere gestiti in modo affidabile in quanto dipendenze operative. Si tratta di una scelta architettonica, non di una garanzia generale di prestazioni.
Per ambienti di hosting consolidati con numerosi casi particolari, il Funzionamento in parallelo di solito l'opzione più flessibile. Permette di individuare quali regole di SpamAssassin siano ancora necessarie, se i simboli di Rspamd rispecchino le cause previste e quali gruppi di destinatari siano particolarmente sensibili alle classificazioni errate. Solo su questa base è possibile decidere se procedere a una transizione completa o se mantenere consapevolmente la configurazione esistente.
La scelta dipende quindi meno dal numero delle caselle di posta in sé e più dalla capacità di manutenzione e dalle dipendenze. Chi è in grado di assumersi in modo permanente la responsabilità di Redis, del resolver DNS, dell’analisi dei log e degli aggiornamenti, può gestire Rspamd in modo coerente, comprese le funzioni di apprendimento e basate sullo stato. In assenza di tali risorse, un sistema snello e ben documentato con regole chiare può rappresentare il rischio operativo minore.
Indipendentemente dal prodotto, vale la regola seguente: non rendere accessibile il controller Rspamd in rete senza protezione. La documentazione raccomanda un collegamento locale o la protezione tramite firewall; in caso di accesso remoto, sono necessari una protezione dell’accesso e un hash della password. Inoltre, non adottare regole di terze parti né punteggi storici senza averli verificati. Singole misurazioni o campagne che destano sospetti non costituiscono una base valida per una politica di filtraggio globale.
La decisione giusta è quindi quella di Valutazione dei rischi: La protezione dai messaggi indesiderati si contrappone alle conseguenze della perdita di e-mail legittime. Definisci per ogni azione chi ne è responsabile, come viene verificata e come è possibile ripristinare lo stato precedente. In questo modo, il filtro antispam rimane una parte controllabile del sistema di posta elettronica, anziché un’entità automatica di difficile comprensione.
Fonti e stato dell'arte
Stato della ricerca:
Ambito delle versioni della ricerca: documentazione di SpamAssassin per il ramo stabile 4.0.x; Rspamd in base alle funzionalità stabili documentate, con la versione 4.2.2 come rilascio su GitHub indicato per il 20 ottobre 2026. I rami di sviluppo e i commit non documentati non sono stati presi in considerazione.
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



