mainly SUSE fetchmail-postfix-spamassassin-procmail impatient-HOWTO

Ripubblico questo documento anche se datato, forse poco attuale e difficile da supportare in quanto sono passato a Debian.

In Debian dpkg rende tutto molto più facile e le modifiche che forse rimangono attuali sono quelle a mailbox_command e a ulteriori configurazioni antispam di postfix

La parte generale può essere utile per farsi un idea generale di come funzioni la posta e a districarsi tra un po' di acronimi

L'augurio è di avere il tempo di dividere questo documento in documenti più compatti e più attuali.

Introduzione

Per un'idea generale di come funzioni tutta la catena di raccolta e consegna delle email potete leggere: La catena di montaggio delle email in un server non pubblico

Questo documento descrive come configurare fetchmail, postfix, spamassassin e procmail per una piccola LAN multiutenza
il cui server di posta elettronica è privato.

Per privato si intende

  • I cui servizi non sono disponibili all'esterno della LAN
  • Che non ha un record MX registrato su un DNS pubblico

Ovvero postfix non viene contattato da server per la consegna della posta.

La prima configurazione proposta sarà per un server con una connessione permanente.
In appendice saranno indicate le modifiche necessarie da apportare qualora si stia usando un dial-up.

Questo HOWTO è un HOWTO per impazienti quindi non si occupa di rispondere ai perchè ne di elencare
le infinite possibilità di configurazione per non distoglere l'attenzione dall'obbiettivo principale:
avere tutto che funziona in fretta.

Questo HOWTO non si occupa di come vanno installati i software in questione, ma di come vanno configurati

La configurazione proposta cercherà di privilegiare la facilità di amministrazione,
l'efficacia dei filtri anti-spam e la comodità del tuning di questi filtri anzichè le performance
o altri fattori. La configurazione di postfix proposta è quindi non chrooted.

L'autore sa benissimo di correre il rischio di essere impreciso sia per ignoranza, sia per semplificare la materia,
sia per la difficoltà di esprimere i concetti in maniera chiara. Per questo i contributi e le correzioni sono
più che benvenute.

Prima di iniziare

Poichè ci prefiggiamo di far attraversare tutta la catena di questi programmi al fine di ordinare la posta in arrivo e
separare lo spam dalla nostra corrispondenza normale è meglio procedere in maniera da poter controllare indipendentemente
se ogni passaggio funziona a dovere.

Inoltre sarebbe meglio fare i test con un indirizzo email di prova, in modo da non perdere posta importante.

Il passo che mette meno a rischio il nostro traffico di posta normale e che è facilmente reversibile è quello di
configurare postfix affinchè si occupi della posta in uscita.

In ordine configureremo poi fetchmail, procmail e modificheremo la configurazione di postfix e infine configureremo
SpamAssassin e modificheremo nuovamente la configurazione di postfix.

Configurazione di postfix

Verrà data una traccia essenziale della configurazione di postfix commentando e soffermandosi solo su quegli aspetti
importanti per lo scopo che ci si prefigge: una configurazione semplice da amministrare e votata a bloccare lo spam.

Per dettagli sull'installazione di postfix e la sua configurazione si rimanda alla documentazione ufficiale di postfix
e a quella della vostra distribuzione.

# /etc/postfix/main.cf
# Che account usa postfix per alcune delle sue mansioni.
# Gli account devono esistere sulla vostra macchina.
# consultate il manuale di postfix o la documentazione della vostra
# distribuzione per sapere come compilare questi campi.
setgid_group = maildrop
mail_owner = postfix

# cosa deve considerarsi appartenente alla vostra rete
#mynetworks = 192.168.1.0/8, 127.0.0.0/8

# il nome della vostra macchina
myhostname = caronte.webthatworks.it

# Se avete un IP esterno fisso potete anche lasciare relayhost vuoto.
# Se avete un IP dinamico è facile che cercando di spedire posta
# direttamente dal vostro server al server di destinazione le email
# vengano bloccate come probabile spam perchè provenienti da una
# fonte non affidabile.
# In questo caso inserite l'indirizzo dello SMTP del vostro provider
relayhost = mail.tin.it

#myorigin = $myhostname
#myorigin = $mydomain

# da dove possono arrivare le connessioni
inet_interfaces = all

# cosa si deve considerare posta locale, ovvero arrivata a destinazione
mydestination = $myhostname, localhost.$mydomain
#mydestination = $myhostname, localhost.$mydomain $mydomain
#mydestination = $myhostname, localhost.$mydomain, $mydomain,
# mail.$mydomain, www.$mydomain, ftp.$mydomain

# riscrittura degli indirizzi in uscita
# se ad esempio la vostra macchina si chiama caronte.webthatworks.it
# ma volete che la posta in uscita risulti spedita da webthatworks.it
# scrivete webthatworks.it in masquerade_domains
masquerade_domains =
masquerade_exceptions = root
masquerade_classes = envelope_sender, header_sender, header_recipient

disable_dns_lookups = no

# di chi fidarsi, di default postfix ha gi&agrave delle impostazioni ragionevoli
#relay_domains = $mydestination

# configurazioni su dove stanno i file e le directory che ha bisogno postfix
sendmail_path = /usr/sbin/sendmail
mailq_path = /usr/bin/mailq
newaliases_path = /usr/sbin/sendmail

manpage_directory = /usr/share/man
sample_directory = /usr/share/doc/packages/postfix/samples
readme_directory = /usr/share/doc/packages/postfix/README_FILES
mail_spool_directory = /var/mail
queue_directory = /var/spool/postfix
command_directory = /usr/sbin
daemon_directory = /usr/lib/postfix

canonical_maps = hash:/etc/postfix/canonical
virtual_maps = hash:/etc/postfix/virtual
relocated_maps = hash:/etc/postfix/relocated
transport_maps = hash:/etc/postfix/transport
sender_canonical_maps = hash:/etc/postfix/sender_canonical
alias_maps = hash:/etc/aliases

# Quante connessioni contemporanee alla stessa destinazione
#local_destination_concurrency_limit = 2
#default_destination_concurrency_limit = 10

# quanto dettagliati devono essere i log
debug_peer_level = 2
# che debugger usare
debugger_command =
PATH=/usr/bin:/usr/X11R6/bin
xxgdb $daemon_directory/$process_name $process_id & sleep 5

In realtà per molti dei parametri suddetti sono sufficienti i valori di default.
Sono stati riportati per darvi un'idea di dove guardare qualora non funzioni qualche cosa.

Ora fate partre postfix
Generalmente:

/etc/init.d/postfix restart

In questo caso vi conviene consultare la documentazione della vostra distribuzione per la
creazione di uno script per lanciare postfix e per farlo partire automaticamente.

Un buon punto di partenza sono le man pages init, init.d, runlevel...

Test di postfix

Configurate il vostro client di posta elettronica perchè usi il vostro server SMTP anzichè
quello del vostro provider. Scrivetevi un email a un indirizzo esterno che sapete che funzioni e vedete se
riuscite a ricevere l'email che vi siete appena spediti.

Per procedere per passi potete prima inserire come indirizzo del vostro server l'IP, se funziona
provate con il suo nome.

Se funziona si può passare a configurare fetchmail.

Configurazione di fetchmail

fetchmail serve per recuperare la posta dai vostri provider o dai server di posta su cui avete caselle di
posta elettronica.

fetchmail può avere un file di configurazione per user o per sistema.

Ci si aspetta che le caselle di posta elettronica non cambino di frequente e che di conseguenza
anche il file di configurazione di fetchmail non cambi di frequente.

Tra i vantaggi di avere un unico file di configurazione per sistema, quello di poter organizzarlo
meglio grazie a dei parametri di default per tutti gli utenti, di gestire meglio i tempi di
download e di risparmiare sul numero delle connessioni.

Esiste un utility per assistervi nella configurazione di fetchmail: fetchmailconf.

Personalmente ho trovato più naturale leggermi la documentazione e scrivere il file manualmente.
Voi potreste potreste preferire l'utility, io non la ho mai provata, YMMV.

# /etc/fetchmailrc
# avvia fetchmail come daemon e preleva la posta ogni 180 secondi
set daemon 180
# usa syslog
set syslog

defaults
    # protocollo di default, se potete IMAP è un ottima scelta.
    proto imap
    # comodo per il debugging e per avere più informazioni sul percorso delle vostre email
    tracepolls
    # il nome dell'utente locale che ha più caselle di posta elettronica sul vostro sistema
    is "ivan" here;
#    i codici d'errore restituiti dallo MTA quando la posta viene rifiutata perchè considerata spam
#    la funzione del parametro sarà più chiara quando verranno trattati ulteriori aspetti
#    della configurazione di postfix
#postfix
    antispam 450,501,504,554
#new sendmail
#    antispam 571
#old exim
#    antispam 501
#Zmailer
#    antispam 500

#    se volete saltare postfix
#    mda procmail

#    poll [server] istruisce fetchmail a connettersi al server per scaricare e cancellare la posta
poll imap.inet.it
    # ID e password della casella sul server
    user "webthatworks.it/info" pass "miapass1";
    user "webthatworks.it/mail01" pass "miapass2";
    # ID, password e nome dell'utente locale (se diverso da default)
    user "webthatworks.it/ronnie" pass "suapass" is "ronnie" here;
# se fetchmail controllerà la posta ogni 180 secondi, questo indirizzo verrà controllato
# ogni 1800 secondi ovvero intervallox10
poll pop.inet.it proto pop3 interval 10
# l'utente locale è ancora ivan
    user "peace" pass "love";
poll box.tin.it auth password
    user "war" pass "wrongchoice"

Una nota per gli utenti Tin.it. Per qualche misterioso motivo (misterioso almeno per me)
il loro server pop3 e IMAP lista tra le CAPABILITY CRAMD-MD5, ma se non impostate fetchmail
per usare una password in chiaro la connessione non va a buon fine.

fetchmail infatti negozia per il protocollo disponibile più sicuro.

Ulteriori dettagli su come configurare fetchmail per usare SSL o configurare fetchmail per esigenze
particolari si possono trovare nella documentazione ufficiale di fetchmail o nelle man page.

Ora non resta che realizzare uno script per far partire fetchmail come servizio nei runlevel 3 e 5.
Segue un esempio che funziona bene su SuSE 8.1 che può essere seguito come traccia per realizzarne uno
per la vostra distribuzione.

#!/bin/sh

# /etc/init.d/fetchmail

### BEGIN INIT INFO
# Provides: fetchmail
# Required-Start: network
# Required-Stop:
# Default-Start: 3 5
# Default-Stop:
# Description: fetchmail daemon
### END INIT INFO


# Check for missing binaries (stale symlinks should not happen)
FETCH_BIN=/usr/bin/fetchmail
test -x $FETCH_BIN || exit 5

# Check for existence of needed config file and read it
# ho scelto di rinominare il file fetchmail.conf anzichè fetchmailrc
# perch&egrave YaST continuava a sovrascrivere il mio
FETCH_SYSCONFIG=/etc/fetchmail.conf
test -r $FETCH_SYSCONFIG || exit 6

# Shell functions sourced from /etc/rc.status:
#      rc_check         check and set local and overall rc status
#      rc_status        check and set local and overall rc status
#      rc_status -v     ditto but be verbose in local rc status
#      rc_status -v -r  ditto and clear the local rc status
#      rc_status -s     display "skipped" and exit with status 3
#      rc_status -u     display "unused" and exit with status 3
#      rc_failed        set local and overall rc status to failed
#      rc_failed <num>  set local and overall rc status to <num>
#      rc_reset         clear local rc status (overall remains)
#      rc_exit          exit appropriate to overall rc status
#      rc_active checks whether a service is activated by symlinks
#      rc_splash arg    sets the boot splash screen to arg (if active)
. /etc/rc.status

# First reset status of this service
rc_reset

# Return values acc. to LSB for all commands but status:
# 0   - success
# 1       - generic or unspecified error
# 2       - invalid or excess argument(s)
# 3       - unimplemented feature (e.g. "reload")
# 4       - user had insufficient privileges
# 5       - program is not installed
# 6       - program is not configured
# 7       - program is not running
# 8--199  - reserved (8--99 LSB, 100--149 distrib, 150--199 appl)
#
# Note that starting an already running service, stopping
# or restarting a not-running service as well as the restart
# with force-reload (in case signaling is not supported) are
# considered a success.

case "$1" in
    start)
    echo -n "Starting fetchmail"
startproc $FETCH_BIN -f $FETCH_SYSCONFIG
rc_status -v
;;
    stop)
echo -n "Shutting down fetchmail "
$FETCH_BIN --quit 2>/dev/null
if [ $? -ne 0 ]
then
    echo -e" I have to kill it or it was not working"
    killproc -TERM $FETCH_BIN
fi
rc_status -v
;;
    try-restart)
$0 status >/dev/null &&  $0 restart
rc_status
;;
    restart)
$0 stop
$0 start
rc_status
;;
    force-reload)
echo -n "Force reload fetchmail"
$0 stop  &&  $0 start
rc_status
;;
    reload)
echo -n "Reload fetchmail"
rc_failed 3
rc_status -v
;;
    status)
echo -n "Checking fetchmail"
checkproc $FETCH_BIN
rc_status -v
;;
    *)
echo "Usage: $0 {start|stop|status|try-restart|restart|force-reload|reload}"
exit 1
;;
esac
rc_exit

Attenzione ai commenti di FETCH_SYSCONFIG=/etc/fetchmail.conf.

A questo punto dovrebbe essere sufficente lanciare:

/etc/init.d/fetchmail restart

Test di fetchmail e postfix

Poichè con la configurazione proposta di fetchmail cancella la posta dal server da cui la
ha recuperata, vi conviene fare prima dei test su un indirizzo di prova onde evitare di perdere
email importanti.

Speditevi un'email a uno degli indirizzi configurati in fetchmail e controllate se la ritrovate nella
vostra INBOX.

Per essere proprio sicuri che tutto funzioni controllate gli header del'email che fetchmail ha
recuperato dal server di posta remoto.

Delivered-To: ivan@localhost.webthatworks.it
Received: from localhost (localhost [127.0.0.1])
by caronte.webthatworks.it (Postfix) with ESMTP id C52114FD52
for <ivan@localhost>; Sat, 29 Mar 2003 15:09:27 +0100 (CET)
Received: from imap.inet.it
by localhost with IMAP (fetchmail-5.9.13 polling imap.inet.it account webthatworks.it/info)
for ivan@localhost (single-drop); Sat, 29 Mar 2003 15:09:27 +0100 (CET)
Received: from  [::ffff:212.216.176.222] by hal-5.inet.it via I-SMTP-4.3.7-430
id ::ffff:212.216.176.222+LLuFTM7JM; Sat, 29 Mar 2003 15:09:26 +0100
Received: from caronte.webthatworks.it (213.45.12.67) by smtp2.cp.tin.it (6.5.033)
        id 3E660875009E8467 for NOSPAM02@webthatworks.it; Sat, 29 Mar 2003 15:09:25 +0100
Received: from stige (stige.webthatworks.it [192.168.1.2])
by caronte.webthatworks.it (Postfix) with ESMTP id 0782F4FD52
for <NOSPAM02@webthatworks.it>; Sat, 29 Mar 2003 15:08:55 +0100 (CET)

Leggendo dall'alto al basso si può vedere il percorso dell'email.

  1. L'email è stata spedita da stige e ricevuta da caronte.

    Se avete spedito l'email dalla macchina che fa girare postfix probabilmente potreste trovare
    from localhost
  2. L'email ha poi raggiunto il server del provider (smtp2.cp.tin.it)

    Questo passaggio potrebbe non comparire se in main.cf relyhost non è stato impostato
    e il vostro server postfix avrebbe contattato il server di destinazione.
  3. Dal server del provider l'email raggiunge il server di destinazione (hal-5.inet.it)
  4. Viene prelevata da fetchmail via IMAP
  5. fetchmail (localhost) la passa via SMTP a postfix (caronte.webthatworks.it)

Il percorso sarà diverso, ma dovreste comunque individuare l'opera di fetchmail e del
vostro server postfix.

Configurazione di procmail

Anche procmail può avere un file di configurazione per user o per sistema.

In questo caso però ci si può aspettare che le preferenze dei singoli utenti siano
più variabili nel tempo e sia meglio renderle più autonome dall'amministratore di
sistema.

Create una directory log nella vostra home, giusto per mantenere le cose ordinate.

# ~/.procmailrc
SHELL=/bin/sh

VERBOSE=no

LOGFILE=${HOME}/log/procmail.log
#LOG="--- Logging ${LOGFILE} for {$LOGNAME}, "

MAILDIR=${HOME}"/Mail"

# FROMENV_=`formail -x "From "`
# TOH_=`formail -zx "To: "`
# FROMH_=`formail -zx "From: "`
YEAR=`date +%Y`
MONTH=`date +%m`

:0:
* ^X-Spam-Flag: YES
${MAILDIR}/SPAM-potential

#:0
#* ^X-Spam-Flag: YES
#/dev/null

:0fhw
| formail -A "X-HSummary: $1 $FROMENV_"

#:0:
#* ^List-Id: .*mailing.list.id
#${MAILDIR}"/ml"

#:0:
#* ^From: .*@domain1\.it|^Sender: .*@domain1\.it|^From: .*@domain1\.com|^Sender: .*@domain2.com
#* ^TO_MAIL01@webthatworks.it|^TO_MAIL02@webthatworks.it
#${MAILDIR}"/server"

#:0:
#* ^TO_lista01@webthatworks.it
#${MAILDIR}"/archivio/lista-"${YEAR}

:0:
${DEFAULT}

Questo è un breve esempio di file di configurazione per procmail.

Sono state inserite alcune regole e parametri che verranno comodi nell'utilizzo di SpamAssassin e dei template per lo smistamento della posta.

formail è un email reformatter, per la lettura/scrittura degli header e altre cose utili.

La differenza tra :0 e :0: stà nel fatto che nel primo caso non viene richiesto il lock del file, mentre nel secondo si.

Le regole cominciano con un *, segue una regular expression l'ultima riga non preceduta da * è l'azione.

^TO_ è una forma generale per intendere i campi dello header che potrebbero contenere il destinatario.

Se intendete mandare lo spam in /dev/null ovviamente non c'è bisogno di alcun lock.

A questo punto conviene modificare il file di configurazione di postfix per fargli utilizzare procmail come MDA.

# /etc/postfix/main.cf
# ...
mailbox_command = /usr/bin/procmail -a "$SENDER $RECIPIENT $EXTENSION"
# ...

Test di procmail e postfix

Per testare se il file di configurazione di procmail proposto funziona inviatevi un email e controllate che negli header dell'email
sia presente lo header X-HSummary

X-HSummary: noreply@dominio.it ivan@localhost.webthatworks.it  noreply@dominio.it  Sat Mar 15 02:07:21 2003

Lo header non deve essere identico a quello presentato ma semplicemente simile.

Configurazione di SpamAssassin

SpamAssassin ha alcuni file di configurazione globale e alcuni file di configurazione personale.

In questo caso il file di configurazione globale ha più che altro funzioni "estetiche".

I file di configurazione presonali sono in parte generati automaticamente e in parte servono
per adattare la sensibilità di SpamAssassin al proprio flusso di email. Ovvero a fargli
capire meglio cosa per voi è spam e cosa no.

SpamAssassin è abbastanza efficace senza nessuna particolare personalizzazione.

Giocare con le regole è un arte a cui forse è meglio lasciar giocare il gruppo degli
sviluppatori di SpamAssassin.

# /etc/mail/spamassassin/local.cf

# riscrive il Subject dell'email aggiungendo ****SPAM**** .* se settato a 1
rewrite_subject 0
# inserisce il report nello header anzich&egrave; nel body dell'email se settato a 1
report_header 1
# report breve se settato a 1
use_terse_report 1
# converte da mime a text/plain se settato a 1
defang_mime 0
# aggiunge solo gli header se settato a 0
report_safe 0
# aggiunge sempre gli header
# always_add_header 0
# punteggio per considerare spam un email
# required_hits 5

Generalmente cerco di lasciare il più possibile le email inalterate, e permettermi semplicemente di dividere
lo lo spam dallo ham e nel contempo fare dell'analisi sullo spam non individuato da SpamAssassin partendo da delle
email il meno alterate possibili da SpamAssassin.

Attraverso delle regole di procmail si può anche dividere le email in fasce di probabilità che un'email sia spam.

Per ottenere informazioni maggiori sulla configurazione di SpamAssassin consultate la man page di Mail::SpamAssassin::Conf.

SpamAssassin si può utilizzare come programma a se stante o in versione client/server.

La versione "standard" occupa meno memoria ma è più lenta.

Ovviamente per far funzionare la versione daemon bisognerà aggiungere uno script apposito in /etc/init.d.
Ne viene presentato uno d'esempio presente nella distribuzione SuSE.
Si rimanda alla documentazione della vostra distribuzione e delle varie man page per ulteriori dettagli.

#!/bin/bash
# Copyright (c) 1995-2002 SuSE GmbH Nuernberg, Germany.
#
# Author: Kurt Garloff <feedback@suse.de>
#
# /etc/init.d/spamd
#
#   and symbolic its link
#
# /usr/sbin/rcspamd
#
# LSB compliant service control script; see http://www.linuxbase.org/spec/
#
# System startup script for daemon spamd
#
### BEGIN INIT INFO
# Provides: spamd
# Required-Start: $remote_fs $syslog
# Required-Stop:  $remote_fs $syslog
# Default-Start:
# Default-Stop:   0 1 2 6
# Description:    Start spamd to allow efficient filtering of mail
# through spamassassin. Note: Read README.spamd about security implications
### END INIT INFO
#
# Note on Required-Start: It does specify the init script ordering,
# not real dependencies. Depencies have to be handled by admin
# resp. the configuration tools (s)he uses.

# Source SuSE config (if still necessary, most info has been moved)
test -r /etc/rc.config && . /etc/rc.config

# Check for missing binaries (stale symlinks should not happen)
SPAMD_BIN=/usr/sbin/spamd
test -x $FOO_BIN || exit 5

# Check for existence of needed config file and read it
#
# Later, we may want to make startup behaviour (user ID, firewalling, ...)
# configurable, as there are security implications (read README.spamd).
SPAMD_CONFIG=/etc/sysconfig/spamd
test -r $SPAMD_CONFIG || exit 6
. $SPAMD_CONFIG

# Shell functions sourced from /etc/rc.status:
#      rc_check         check and set local and overall rc status
#      rc_status        check and set local and overall rc status
#      rc_status -v     ditto but be verbose in local rc status
#      rc_status -v -r  ditto and clear the local rc status
#      rc_failed        set local and overall rc status to failed
#      rc_failed <num>  set local and overall rc status to <num><num>
#      rc_reset         clear local rc status (overall remains)
#      rc_exit          exit appropriate to overall rc status
#      rc_active checks whether a service is activated by symlinks
. /etc/rc.status

# First reset status of this service
rc_reset

# Return values acc. to LSB for all commands but status:
# 0 - success
# 1 - generic or unspecified error
# 2 - invalid or excess argument(s)
# 3 - unimplemented feature (e.g. "reload")
# 4 - insufficient privilege
# 5 - program is not installed
# 6 - program is not configured
# 7 - program is not running
#
# Note that starting an already running service, stopping
# or restarting a not-running service as well as the restart
# with force-reload (in case signalling is not supported) are
# considered a success.

case "$1" in
    start)
echo -n "Starting spamd "
test -d /root/.spamassassin || mkdir /root/.spamassassin
## Start daemon with startproc(8). If this fails
## the echo return value is set appropriate.

# NOTE: startproc returns 0, even if service is
# already running to match LSB spec.
startproc $SPAMD_BIN $SPAMD_ARGS

# Remember status and be verbose
rc_status -v
;;
    stop)
echo -n "Shutting down spamd "
## Stop daemon with killproc(8) and if this fails
## set echo the echo return value.

killproc -TERM $SPAMD_BIN

# Remember status and be verbose
rc_status -v
;;
    try-restart)
## Stop the service and if this succeeds (i.e. the
## service was running before), start it again.
## Note: try-restart is not (yet) part of LSB (as of 0.7.5)
$0 status >/dev/null &&  $0 restart

# Remember status and be quiet
rc_status
;;
    restart)
## Stop the service and regardless of whether it was
## running or not, start it again.
$0 stop
$0 start

# Remember status and be quiet
rc_status
;;
    force-reload)
## Signal the daemon to reload its config. Most daemons
## do this on signal 1 (SIGHUP).
## If it does not support it, restart.

echo -n "Reload service spamd "
## if it supports it:
#killproc -HUP $SPAMD_BIN
#touch /var/run/spamd.pid
#rc_status -v

## Otherwise:
$0 stop  &&  $0 start
rc_status
;;
    reload)
## Like force-reload, but if daemon does not support
## signalling, do nothing (!)

# If it supports signalling:
#echo -n "Reload service spamd "
#killproc -HUP $SPAMD_BIN
#touch /var/run/spamd.pid
#rc_status -v

## Otherwise if it does not support reload:
rc_failed 3
rc_status -v
;;
    status)
echo -n "Checking for service spamd "
## Check status with checkproc(8), if process is running
## checkproc will return with exit status 0.

# Return value is slightly different for the status command:
# 0 - service running
# 1 - service dead, but /var/run/  pid  file exists
# 2 - service dead, but /var/lock/ lock file exists
# 3 - service not running

# NOTE: checkproc returns LSB compliant status values.
checkproc $SPAMD_BIN
rc_status -v
;;
    probe)
## Optional: Probe for the necessity of a reload,
## print out the argument which is required for a reload.

test /etc/mail/spamassassin/local.cf -nt /var/run/spamd.pid && echo reload
;;
    *)
echo "Usage: $0 {start|stop|status|try-restart|restart|force-reload|reload|probe}"
exit 1
;;
esac
rc_exit

Per far funzionare il tutto manca l'ultima modifica a main.fc di postfix.

# /etc/postfix/main.cf
...
# versione client/server
mailbox_command = /usr/bin/spamc | /usr/bin/procmail -a "$SENDER $RECIPIENT $EXTENSION"
# versione programma singolo
mailbox_command = /usr/bin/spamassassin | /usr/bin/procmail -a "$SENDER $RECIPIENT $EXTENSION"
...

Test di SpamAssassin

Se tutto è stato configurato a dovere, le email che ricevete dovrebbero contenere almeno uno dei seguenti header:

X-Spam-Status: No, hits=-31.0 required=5.0
tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,
      REFERENCES,REPLY_WITH_QUOTES,SIGNATURE_LONG_SPARSE
autolearn=ham version=2.50
X-Spam-Level:
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)

Se anche la regola di procmail per individuare lo spam funziona, la prossima email sospetta dovrebbe finire
in una mbox di nome SPAM-potential.

Giocare con SpamAssassin

...ovvero, come sprecare il tempo che pensavate di risparmiare.

Ci sono però un po' di cose che potreste essere interessati a fare:

  1. Addestrare il vostro filtro bayesiano
  2. Segnalare spam via Razor, Pyzor e DCC
  3. Agire sulla whitelist

Personalmente il tempo che ho impiegato ad addestrare il filtro bayesiano non ha portato a evidenti
miglioramenti. Probabilmente si dovrebbe agire anche sui pesi. Questo è un vero peccato
perchè la principale attrattiva dei filtri bayesiani ` quella dell'auto adattamento.

Se la principale funzione di un filtro antispam è quella di evitare che lo spam ci rubi del tempo
un filtro bayesiano è ha certamente un suo fascino, se però per farlo funzionare
bisogna perdere del tempo analizzando spam, questo suo fascino è perso.

Il comando per istruire il filtro bayesiano è sa-learn.

#!/bin/sh
# esempio d'uso
sa-learn --spam --rebuild --mbox ~/Mail/SPAM-missed

Razor invece è piuttosto efficace nel dividere spam da ham, potremmo essere quindi interessati
a contribuire al suo funzionamento segnalando le email che consideriamo spam ma che non sono state
individuate da SpamAssassin.

Questo lavoro va fatto manualmente ma si può automatizzarne almeno una parte.

Se collezionate lo spam non individuato in una mbox o maildir potete poi segnalarlo a Razor con uno
script avviato da cron

Razor è tanto più utile per gli altri, quanto più le segnalazioni sono tempestive.

# per segnalare un messaggio come spam
spamassassin -r < messaggio
# per eliminare un messaggio dai vari spam blocker DB
spamassassin -k < messaggio
# elimina gli header di Spamassassin
spamassassin -d < messaggioIN >massaggioOUT

Per fare un buon lavoro l'email di spam dovrebbe essere il più simile possibile all'originale,
quindi senza gli header eventualmente aggiunti dal primo passaggio attraverso SpamAssassin e senza quelli
aggiunti da postfix o formail o quant'altro.

Le whitelist hanno senso solo se avete pessimi contatti che si ostinano a mandarvi email che assomigliano
incredibilmente a spam e forse è venuto il tempo per "educarli" a mandarvi qualche cosa di più decente
o se siete iscritti a una mailing list in cui si discute di spam dove parte della corrispondenza sarà
costituita da "reperti" di spam.

Le blacklist hanno più senso implementate in postfix, tranne rari casi.

Per sapere come aggiungere o togliere indirizzi dalle white/black list è sufficiente consultare la man
page di spamassassin.

Configurare postfix per difendersi dallo spam

Se usate fetchmail molti dei filtri che si potrebbero applicare già a livello di postfix sono
inefficaci. Se non siete proprio paranoici (e la cosa non è da considerarsi un difetto) potete evitare
di applicare molte regole che dovrebbero essere inutili se il vostro server non è accessibile
dall'esterno.

Di seguito verrà riportato un esempio di ulteriori parametri che possono contribuire a eliminare lo
spam in maniera più efficiente prima che venga esaminato da SpamAssassin e verranno commentati solo
quei parametri che hanno un senso per una configurazione che sfrutta fetchmail.

# smtpd_delay_reject = no

# inutile se la posta arriva via fetchmail
# local_recipient_maps = $alias_maps unix:passwd.byname

# questo pu&ograve; funzionare da blacklist per i mittenti
smtpd_sender_restrictions = hash:/etc/postfix/access
# reject_unknown_sender_domain, reject_non_fqdn_sender; a volte drastici
# reject_rhsbl_sender domain.tld; comodo

# anche questo pu&ograve; essere usato da blacklist
# header_checks = regexp:/etc/postfix/header_checks

# inutile se la posta arriva via fetchmail, ma prudente
smtpd_recipient_restrictions = permit_mynetworks,check_relay_domains

# di questo &egrave; meglio che se ne occupi SpamAssassin
# body_checks = regexp:/etc/postfix/body_checks
# content_filter =

# inutili quando si usa fetchmail
# smtpd_helo_required = no
# smtpd_helo_restrictions =
# strict_rfc821_envelopes = no

# utile solo se postfix funziona come full fladged MTA, quindi senza fetchmail
# smtpd_client_restrictions = hash:/etc/postfix/access, reject_rbl_client relays.ordb.org

Sostanzialmente fetchmail modifica l'envelope e la "sorgente" dell'email quindi molti
dei controlli sono vani.

Ringraziamenti

  • Maurizio Lemmo
  • Davide Bolcioni
  • Wietse Venema

Bibliografia