Installazione configurazione di simscan

28 luglio 2021 Roberto Puzzanghera 5 commenti

Simscan è un semplice programma che abilita il servizio qmail smtpd a rigettare virus , spam e a bloccare allegati durante la conversazione SMTP in modo da ridurre al minimo il carico per il sistema.

Dettagli sulla patch applicata

La versione 1.4.1 è un fork del programma originale di Inter7. I sorgenti sono stati ripuliti e leggermente modernizzati (per evitare vari warming durante la compilazione), contegono varie correzioni di bug e patche, tra le quali quasi tutte quelle di John Simpson (l'unica mancante è la patch "debug" che applicheremo comunque, come mostrato sotto) e il bug fix di Gustavo Castro che era presente nella mia precedente patch combinata. Pertanto la nuova patch agginge solamente solo quanto segue:

  • La debug patch di John Simpson, che consente di migliorare il debud a livello di qmail-smtpd (maggiori informazioni nel sito di jms);
  • un bug fix di Bob Greco secondo il quale un messaggio ricevuto con destinatari locali multipli eseguiva spamc come utente null invece di estrarre il nome utente dal primo destinatario.
    Maggiori informazioni qui https://notes.sagredo.eu/en/qmail-notes-185/simscan-38.html#comment844
  • La mia patch attachments-size-limit che consente di superare un limite di simscan per cui i messaggi con allegati di dimensione superiore a 250k non vengono passati a spamassassin. Questa patch consente di impostare la dimensione massima degli allegati in bytes in fase di compilazione configurando il programma in questo modo

    autoreconf -f -i (questo è necessario dal momento che il file configure.ac è stato modificato)
    configure --with-attachments-size-limit=500000 (default 250k, valore numerico in bytes)

    Inoltre, gli eventi per cui simscan non viene attivato vengono ora loggati a livello smtpd anche senza attivare l'opzione debug.

Razor2, Pyzor, Spamcop e DCC

14 luglio 2021 Roberto Puzzanghera 0 commenti

Questa pagina concerne il setup di alcuni filtri di rete che aiutano spamassassin a decidere cosa fare di un dato messaggio. Abilitando questi filtri, insieme al sistema di apprendimento bayesiano, migliorerà drasticamente le prestazioni di spamassassin nella lotta allo spamming.

Spamassassin User Preferences via SQL

12 luglio 2021 Roberto Puzzanghera 6 commenti

Info: http://spamassassin.apache.org/dist/sql/README - http://wiki.apache.org/spamassassin/UsingSQL

SpamAssassin può ora caricare gli score da un database SQL.  L'obiettivo è far sì che una applicazione web (PHP/perl/ASP/etc.) possa consentire agli utenti di aggiornare le loro preferenze su come SpamAssassin debba filtrare la loro posta. L'uso più comune per un sistema come questo è quello in cui gli utenti aggiornano la white/black list di indirizzi senza bisogno di di aggiornare il file $HOME/.spamassassin/user_prefs.

Si può saltare questa pagina nel caso si voglia consentire solo l'uso di opzioni globali su tutto il server via /etc/mail/spamassassin.

Tenere presente che le regole per la gestione dello spamming a livello utente saranno facilmente gestite per mezzo del plugin "sauprefs" della webmail Rouncube.

Changelog

  • 12 luglio 2021
    la lunghezza del campo varchar "preference" nella tabella userprefs del database è stata aumentata a 50 (era 30) per consentire il salvataggio di variabili lunghe come ad esempio  "bayes_auto_learn_threshold_spam", che veniva troncata prima della modifica.

Script e cronjob per il sistema di learning e reporting di Spamassassin

20 giugno 2021 Roberto Puzzanghera 0 commenti

Ora che abbiamo preparato i filtri antispam dobbiamo addestrare il nostro sistema bayesiano e inviare i report a Razor, Pyzor e Spamcop.

La cosa più ovvia che può venirci in mente di fare a questo punto è forse quella di lanciare sa_learn e spamassassin --report uno dopo l'altro al click sul bottone "Marca come Spam" della webmail Roundcube (vedere i driver cmd_learn e multi_driver del plugin markasjunk), ma questa scelta ha alcuni svantaggi importanti:

  • il processo di addestramento, la conseguente sincronizzazione del journal e la connessione ai vari network per il reporting può richiedere anche una decina di secondi, un tempo che i nostri utenti non sono disposti ad attendere.
  • cosa anche più grave, quando essi cliccano sul bottone "Marca come Spam" non è sempre detto che si tratti di un vero messaggo di posta indesiderata. Prendiamo ad esempio il classico caso delle newsletter a cui si sono regolarmente iscritti e che non vogliono più leggere, e che decidono di eliminare etichettandole come spamming anzichè inoltrare una regolare richiesta di cancellazione.

E' qundi più corretto eseguire questi due compiti durante la notte per mezzo di un cronjob (primo problema risolto), processando i soli messaggi di vero spam/ham che l'utente ha consapevolmente copiato in una cartella apposita (secondo problema).