Mail server con Exim4 / Dovecot / Clamav / Spamassassin / Greylistd

Aggiornato per Debian Jessie e Wheezy con annotazioni per Squeeze

Le vecchie versioni sono disponibili consultando le versioni precedenti di questa pagina, se servissero ancora a qualcuno.

11 aprile 2013 - aggiunto supporto per Greylistd. Il supporto per greylistd e` disattivato di default. Per configurare greylistd fare riferimento a ../GreyListd

11 gennaio 2012 - aggiunta gestione user e group nelle pipe. Aggiunta la possibilita` di definire quale utente e gruppo usare quando si lancia una pipe dal file degli alias (ovvero quando si ha un alias del tipo "|script").

06 novembre 2011 - Corretto bug logico nella gestione del "sender callout verify". Messa la condition prima del verify nelle due ACL che verificano il mittente facendo un callout al suo mail server. Questo mi evita di fare una grossa idiozia, cioe` fare comunque la chiamata e poi eventualmente ignorarne il risultato. Ora se la funzione non e` abilitata (SPAM_CHECK_SENDER=none) la chiamata smtp non viene fatta, come e` logico che sia.

23 Feb 2011 - Corretto bug logico nella gestione dello spam. Ho scambiato di ordine i due director che mettono lo spam in un folder apposito se impostato con l'opzione "spam_folder" e quello che applica i filtri utente, in modo che il primo abbia la precedeza sul secondo.

29 gennaio 2010 - ATTENZIONE: corretto un bug nell'autenticazione SMTP CRAM_MD5 su file di testo (/etc/exim4/passwd.smtp). Questo bug non dovrebbe colpire l'autenticazione su Dovecot. Il file per Etch e Lenny e` stato corretto, anche se comunque gli autenticatori in testo sono commentati per default. Il file per Sarge non e` stato corretto.

18 gennaio 2010 - Aggiunta la possibilita` di marcare lo spam e salvarlo in una directory IMAP specifica per utente

16 ottobre 2008 - ATTENZIONE: corretto un bug che consentiva di saltare l'autenticazione SMTP. Il file di configurazione allegato ora e` corretto. La modifica consiste nel togliere la stringa "{*:*}" da tutti gli autenticatori.

Questa e` una configurazione di un mail server completo, con supporto per diversi domini, antivirus e antispam. Le configurazioni sono realizzate su files di testo e non su database in quanto ritengo che sia piu` facile, per piccole installazioni che possono essere gestite da un sistemista che sa come editare un file di testo, evitare di usare un database e una interfaccia web per la configurazione. (Nutella ne sta facendo una versione con postgres e una interfaccia web realizzata appositamente, forse la pubblicheremo)

Descrizione tecnica

Questo sistema deve fornire un mail server con funzione di filtraggio dei virus e dello spam, supporto per client pop3 e imap4, e gestione di diversi domini virtuali. La configurazione e` fatta tutta su files di testo, ed e` studiata per essere semplice da gestire, ovvero per aggregare tutti i dati in pochi files per ogni dominio virtuale. Usando dei programmi come Dovecot ed Exim, che sono molto configurabili, e` possibile fare in modo che tutti e due accedano agli stessi files, e li usino "assieme", exim per decidere come fare il delivery della mail, e dovecot per autenticare gli utenti pop3 e imap4. Per lo storage della mail ho scelto di usare maildir, perche` e` molto piu` performante di mailbox, e se si vuole usare imap secondo me la velocita` e` fondamentale. Prevedendo di usare solo pop3, oppure accontentandosi di prestazioni scarse in imap, si puo` anche usare il formato mailbox. La mail viene comunque tutta tenuta in files e directory di proprieta` dell'utente "mail" sotto /var/vmail/<dominio>/<utente>. Gli utenti mail in questo setup sono totalmente svincolati dagli utenti locali della macchina. Usando questa configurazione un mail server che abbia soltanto un dominio deve comunque essere configurato in modo che il dominio sia virtuale, e gli utenti locali della macchina non abbiano nulla a che fare con gli utenti della mail.

I motivi di questa scelta sono diversi: prima di tutto gli utenti della macchina (per come e` configurato exim) non hanno ne` l'antivirus ne` l'antispam, inoltre gli utenti della macchina accederebbero in pop3 e imap usando la stessa password di login, e questo e` decisamente male dal punto di vista della sicurezza. Tra l'altro al momento Dovecot e` configurato in modo da non riconoscere proprio gli utenti della macchina, quindi questi non potrebbero proprio ricevere la mail in pop3 o imap4, ma solo leggerla localmente in shell.

Funzionamento del sistema antispam e antivirus

Idealmente, avrei voluto permettere ad ogni singolo utente di scegliere cosa fare dello spam, permettendogli di scegliere se bloccare (nel senso di rifiutare la mail a livello di protocollo SMTP rifiutandola con una permanent failure), oppure marcare con un header X-Spam-qualcosa le mail di spam, oppure non fare proprio il controllo antispam. Purtroppo questo e` un problema quando ci sono degli alias in gioco, perche` al momento in cui faccio il check (cioe` alla fine del blocco "DATA" dell'smtp) non sono in grado di determinare se il destinatario ultimo di una mail che viene diretta ad un alias vuole o no la funzione antispam/antivirus, per saperlo dovrei espandere l'alias fino agli indirizzi finali, e se questi sono piu` di uno e richiedono comportamenti diversi, ancora non saprei come comportarmi. Per uscire da questa impasse ci sono due soluzioni: una delle due e` quella di non fare il controllo antispam al momento della connessione SMTP entrante ma farlo al momento del delivery locale (questo metodo pero` mi impedisce di rifiutare il messaggio, ma mi costringe ad accettarlo e poi eventualmente cancellarlo) e l'altra e` quella che ho usato e che spiego nel dettaglio qui sotto.

Quando una mail arriva al sistema, passa per una serie di ACL che ne controllano la validita` e decidono cosa farne.

A questo punto la mail viene accettata a livello di SMTP, ma lo spam puo` ancora essere trattato a livello di utente, e questa volta non ci sono problemi nell'identificare il destinatario, quindi ogni destinatario "finale" (dopo che sono stati elaborati alias e domain_alias) puo` fare dello spam quello che vuole. Le possibilita` che ha sono:

Pacchetti

I pacchetti usati sono: 

dovecot-imapd  dovecot-pop3d exim4-daemon-heavy  clamav-daemon  spamassassin razor

Se vi serve solo l' MX secondario potete evitare di installare Dovecot, pero` poi dovrete modificare la configurazione di Exim in modo da non appoggiarsi all'autenticatore di Dovecot.

Configurazione di Dovecot versione 2.x (attuale)

Dovecot va configurato per servire pop3 e imap4 usando delle maildir. Lavora sempre come uid "mail" e gid "mail", per qualsiasi utente di qualsiasi dominio. Legge le password in chiaro (necessario per poter usare autenticazioni in cui la password non viaggia in chiaro sulla linea) da un file di testo. Se si vuole usare mailbox, basta cambiare la parola "maildir" in "mailbox" (ovviamente anche exim andra` adattato per lavorare in mailbox e non in maildir). La configurazione ` in /etc/dovecot/dovecot.conf. Vale la pena di leggersi la documentazione perche` questa configurazione e` funzionante ma minimale, ci sono mille features che possono essere messe a punto come meglio credete. Soprattutto, leggete le parti che riguardano i tweak per la compatibilita` con i client imap rognosi. (vedasi la documentazione su http://www.dovecot.org)

Se volete attivare il supporto SSL, occorre generare delle chiavi, siano esse "buone" o fatte in casa. Per generare al volo delle chiavi fatte in casa si puo` eseguire uno script che ha lo scopo di generare una coppia certificato/chiave e di metterla dove Dovecot si aspetta di trovarla. Prima modificare (volendo) la configurazione per metterci due cose sensate, e poi eseguire mkcert, come indicato qui di seguito: 

vim /usr/share/dovecot/dovecot-openssl.cnf
cd /usr/share/dovecot
./mkcert.sh

Se si usano chiavi firmate da una CA valida, non dovrebbero sorgere problemi di sorta. Dovecot usa tranquillamente le chiavi nello stesso formato in cui sono comprese da apache2, per esempio. L'unico punto complesso riguarda il "chaining" dei certificati. Se la CA che usiamo non e` una CA riconosciuta "direttamente", ma richiede un chaining dei certificati allora dobbiamo avere cura di mettere nel file pem dei certificati (in /etc/ssl/certs) tutti i certificati in sequenza. Se non sapete che CA usare, io ho preso i miei certificati presso Namecheap (Rapidssl), costano poco e funzionano bene, e li uso sia in Exim che in Dovecot che anche in Apache per https.

Questo e` il file /etc/dovecot/dovecot.conf, che non utilizza alcuna altra configurazione (ne` i files dentro conf.d ne` la configurazione del database, in questo caso) 

##
## usa questi protocolli (le versioni "s" sono comprese, quindi
## imap include imaps e pop3 include pop3s)
##
protocols = imap pop3

##
## autenticatori che accetto (tolgo ntlm, nel caso lo rimettero`)
##
   # auth_mechanisms = plain login digest-md5 cram-md5 apop ntlm
auth_mechanisms = plain login digest-md5 cram-md5 apop

##
## Patch per disabilitare SSLv3 e inferiori.
## Visto il bug disastroso di SSLv3 (15/10/14)
##
ssl_protocols = !SSLv2 !SSLv3


##
## Consenti l'autenticazione plaintext sempre, anche senza SSL.
## Non e` sicuro ma lo uso in locale con la webmail
##
disable_plaintext_auth = no


##
## Consenti di usare l' UID 8 per accedere alla mail
## (visto che tutta la mia mail dei virtual domanins e` di questo utente)
##
first_valid_uid = 8
last_valid_uid  = 8
first_valid_gid = 8
last_valid_gid  = 8


##
## Carica il certificato e la chiave privata per SSL da qui:
##
ssl_cert = </etc/dovecot/dovecot.pem
ssl_key = </etc/dovecot/private/dovecot.pem


##
## Mostra in "ps" chi e` l'utente che usa il processo
##
verbose_proctitle = yes


##
## Scrive nel log le date come le voglio io
##
log_timestamp = "%Y-%m-%d %H:%M:%S "


##
## Per loggare tutte le azioni degli utenti imap e pop serve questo plugin
##
mail_plugins = $mail_plugins mail_log notify
plugin {
  # Events to log. Also available: flag_change save mailbox_create
  mail_log_events = delete undelete expunge copy mailbox_delete mailbox_rename save mailbox_create

  # Also available: flags vsize from subject
  mail_log_fields = uid box msgid size from subject
}


##
## Per debuggare. TOGLILI QUANDO FUNZIONA!
##
# auth_debug_passwords = yes
# mail_debug = yes
# verbose_ssl = yes

##
## Questa credo che serva solo per i lock delle mailbox e non delle maildir, ma male non fa.
##
mail_privileged_group = mail


##
## Configurazioni generali del sistema di autenticazione
##
service auth {
  user = Debian-exim
  # questo socket e` quello su cui si autentica Exim per l' SMTP autenticato
  unix_listener auth-client {
    mode = 0666
  }
}


##
## Configurazione dell'autenticazione degli utenti su file di testo
## diviso in due parti:
## - passdb definisce da che database (files di testo in questo caso) leggo username
##   e password e in che formato li leggo
## - userdb definisce dove si trova la mail e come la si accede a seconda
##   di che utente sei (in questa config e` uguale per tutti, tranne che per
##   il percorso dei files della maildir, infatti uso un driver "static")
##
passdb {
  args = username_format=%n scheme=plain /etc/vmail/users/%d
  driver = passwd-file
}

userdb {
  args = uid=mail gid=mail home=/var/vmail/%d/%n mail=maildir:/var/vmail/%d/%n
  driver = static
}


##
## configurazioni del protocollo imap
##
protocol imap {
  imap_client_workarounds =
  mail_max_userip_connections = 30
}


##
## configurazioni del protocollo pop
##
protocol pop3 {
  pop3_logout_format = top=%t/%T, retr=%r/%R, del=%d/%m, size=%s
  pop3_uidl_format = %08Xu%08Xv
}

Configurazione di Dovecot versione 1.x

Questa configurazione e` per Dovecot 1.x (Lenny, Squeeze) ed e` obsoleta se usate Wheezy o se vi siete compilati Dovecot da soli.

A partire dalla versione di Dovecot in Squeeze, e` necessario specificare lo "username_format" dentro l'autenticatore. Gia` che ci sono, ho anche specificato che la crittografia di default delle password e` "plain", quindi nel file degli utenti non e` piu` necessario usare {plain} prima di ogni password. Lasciarlo comunque non fa danni. 

# Protocols we want to be serving:
#  imap imaps pop3 pop3s
protocols = imap pop3 imaps pop3s

# mostra in "ps" il nome dell'utente collegato
verbose_proctitle = yes

# Prefix for each line written to log file. % codes are in strftime(3)
# format.
log_timestamp = "%Y-%m-%d %H:%M:%S "

# Consenti di usare l' UID 8 per fare login
first_valid_uid = 8
last_valid_uid = 8

# Consenti l'autenticazione plaintext
disable_plaintext_auth = no

# Per debuggare l'autenticazione... TOGLILO QUANDO FUNZIONA!
# auth_debug_passwords=yes


# Grant access to these extra groups for mail processes. Typical use would be
# to give "mail" group write access to /var/mail to be able to create dotlocks.
mail_privileged_group = mail


##
## IMAP specific settings
##

protocol imap {
  imap_client_workarounds = outlook-idle
  mail_max_userip_connections = 30
}

##
## POP3 specific settings
##

protocol pop3 {
  pop3_uidl_format = %08Xu%08Xv
  pop3_logout_format = top=%t/%T, retr=%r/%R, del=%d/%m, size=%s
}

##
## AUTH backend su files di testo.
##

auth default {
  mechanisms = plain login digest-md5 cram-md5 apop ntlm
  user = Debian-exim
  userdb static {
   args = uid=mail gid=mail home=/var/vmail/%d/%n mail=maildir:/var/vmail/%d/%n
  }
 # un file per dominio, con il nome di file <dominio.tld>
 passdb passwd-file {
  args = username_format=%n scheme=plain /etc/vmail/users/%d
 }
# socket per fare autenticare Exim (smtp) su Dovecot
 socket listen {
    client {
      path = /var/run/dovecot/auth-client
      mode = 0666
    }
 }
}

Configurazione di Exim

Prima di tutto, occorre fare alcune operazioni a livello di file system:

Il consiglio e` quello di fare un chown root.Debian-exim e poi un chmod 640 dei files.

Poi, eliminare tutte le porcherie che Debian mette nella directory /etc/exim4 (se vi piace, conservatele da qualche parte) e crearci dentro un unico file di configurazione monolitico come era per exim3, che almeno cosi` ci si capisce qualcosa.

Il file exim4.conf lo devo allegare perche` contiene una serie di parentesi graffe che mandano in crisi il renderer del markup language del wiki; lo trovate qui per Etch, Lenny, Squeeze e Wheezy: exim4.conf.etch-lenny-squeeze

Nella configurazione allegata uso dei retry molto frequenti per velocizzare l'invio di email a destinatari che usino la greylist. Questo pero` richiede che Exim esegua il run della coda piu` spesso dei 30 minuti standard in Debian. Per ridurre questo tempo, occorre modificare il file /etc/default/exim4 modificando il valore QUEUEINTERVAL, cosi`: 

# how often should we run the queue
QUEUEINTERVAL='5m'

NOTE:

Configurazione di Spamassassin

In questo setup, spamassassin (in realta` il demone spamd) viene sempre chiamato dall'utente "mail", quindi per qualsiasi utente di qualsiasi dominio il database bayesiano sara` sempre lo stesso, e si trovera` nella home dell'utente mail sotto una directory con nome ".spamassassin".

Configurazione di Razor

* Editare il file /etc/razor/razor-agent.conf modificandolo come segue: 

logfile = sys-syslog
logic_method = 4
ignorelist = 1
report_headers = 0

# su - mail -s /bin/bash
$ razor-admin -create
$ razor-admin -discover
$ razor-admin -register

Le configurazioni di Razor saranno salvate sotto la home dell'utente mail, nella directory ".razor".

Configurazione di Clamav

Dopo aver installato clamd (questa config usa clamd e non clamscan), occorre aggiungere l'utente "clamav" al gruppo "Debian-exim" e al gruppo "mail" dentro /etc/group, altrimenti clamd non puo` accedere ai files che exim gli passa da scansionare. 

adduser clamav mail
adduser clamav Debian-exim

Occorre anche verificare che nel file /etc/clamav/clamd.conf vi sia la direttiva AllowSupplementaryGroups true altrimenti clamd ignora i gruppi ai quali l'abbiamo appena aggiunto.

Dopo aver fatto questa modifica riavviare clamd.

Configurazione del greylisting (facoltativo)

Per abilitare il supporto al greylisting occorre configurare greylistd (come indicato qui: ../GreyListd) e poi modificare file di configurazione /etc/exim4/exim4.conf (nella parte iniziale) impostando la variabile GREYLISTING che di default e` disabled, a enabled. Vale la pena di soffermarsi sul fatto che se usiamo un MX secondario oltre al primario e vogliamo abilitare il greylisting, e` fondamentale configurare i due MX per avere le stesse regole di greylisting (o se non altro per avere il greylisting tutti e due) altrimenti e` inutile metterlo solo su uno dei due: le mail che vorremmo bloccare con il greylisting verranno fatte passare per l'altro. E` anche opportuno mettere l' MX secondario in whitelist in modo che non sia mai soggetto a greylisting da parte del primario. In ogni caso e` una buona idea mettere il proprio MX secondario in whitelist.

Scripting per insegnare al filtro bayesiano di Spamassassin (facoltativo)

Volendo e` possibile installare un sistema per insegnare al filtro bayesiano di Spamassassin. Dal momento che noi di default rifiutiamo lo spam, non avremo mai delle mail buone indicate come "SPAM" (falsi positivi) nella nostra inbox, saranno tutte state rimandate al mittente con un errore. Questo e` un limite intrinseco nella scelta di rifiutare lo spam, ma a me va bene cosi`. Comunque, ci resta la possibilita` di ricevere dello spam che il filtro non ha identificato correttamente (falsi negativi), e per questi possiamo provare a insegnare al filtro bayesiano come trattarli.

Questo sistema richiede che l'utente crei una cartella IMAP denominata "SPAM" sotto la sua cartella principale (NON SOTTO LA INBOX!) in modo che nella gerarchia delle directory sul server questa venga creata come /var/vmail/dominio/utente/.SPAM.

Lo script qui allegato, che va messo in crontab, cerca tutte le directory denominate ".SPAM" nel percorso sopra indicato, e ne "processa" il contenuto, passando le mail che ci sono dentro a Spamassassin per insegnargli che questo e` spam, dopodiche` cancella le email in questione. In pratica cosi` facendo l'utente deve solo spostare lo spam che riceve nella cartella SPAM, e il sistema provvedera` ad imparare che quelle mail sono spam, e poi a cancellarle.

Questo e` lo script /usr/local/sbin/sa-learn-from-maildir: 

# insegna a spamsassassin leggendo la mail dai folder imap.
# adattato dallo script originale che si trova qui: http://wiki.yobi.be/wiki/Spamassassin

[ -x /usr/bin/sa-learn ] || exit 0

# Cerco i folder di nome "SPAM" (che diventa ".SPAM") all'interno del root
# folder di ogni utente (per questo uso il maxdepth). Non cercare oltre
# questa profondita` velocizza il processo, e a me sta bene avere il folder SPAM sotto la root
# per ogni utente e non dove pare a lui.

for i in $(find /var/vmail/ -maxdepth 3 -name .SPAM -type d);
do
    if [ -d $i/cur ];
    then
        # Get the mails to train spamassassin
        for f in $i/cur/*; do
                if [ -e $f ]; then
                       # Debian-exim does not have read access to the mails so we pipe them
                       cat $f|su - -s /bin/bash Debian-exim -c "sa-learn --spam" |grep -v "Learned tokens from"
                       rm -f $f
                fi
        done
    fi;
done
exit 0

Questo script va reso eseguibile da root, e poi richiamato da cron, tipo cosi`: 

# learn dello spam ogni ora
15 * * * *      root    /usr/local/sbin/sa-learn-from-maildir

Configurazione dei domini virtuali

Alla fine, se vogliamo che funzioni qualcosa, occorre definire almeno un dominio virtuale.

Per creare un dominio virtuale che abbia degli utenti, e` sufficiente creare un file con il nome del dominio dentro a /etc/vmail/users/ Per esempio, /etc/vmail/users/pippo.com e` il file che contiene gli utenti del dominio "pippo.com".

Questo file e` composto di tante righe quante sono gli utenti, ognuna delle quali contiene username, password (in chiaro), ed eventualmente variabili che dicono come comportarsi con la scansione antivirus e antispam per l'utente. Queste variabili, facoltative, sono separate dalla password con un carattere ":" e sono separate fra di loro da spazi. Al momento esistono le seguenti variabili:

Quello che segue e` un esempio di file di configurazione per un dominio, contenente diversi utenti con diversi parametri. Notare che la sintassi per la password e` necessariamente "{plain}" seguito dalla password che volete, senza spazi in mezzo. 

utente1:{plain}password1:virus=off
utente2:{plain}password2:spam_smtp_deny=50 spam_blackhole=50 spam_subject=20
utente3:{plain}password3
utente4:{plain}password4:spam_subject=20 spam_blackhole=50
utente5:{plain}password5:spam_folder=PostaSpazzatura

Nei nomi utente e nelle password NON SI POSSONO USARE i ":" che sono riservati alla separazione dei campi fra loro.

Per avere degli alias nel dominio virtuale "pippo.com", occorre creare un file /etc/vmail/aliases/pippo.com. Questo file contiene un alias seguito da ":" e poi da tanti indirizzi mail quanti si vuole, sia appartenenti al dominio che no, eventualmente seguiti da ":" e dalla variabile "spam_smtp_deny=xx" per decidere a quale soglia rifiutare lo spam diretto all'alias a livello SMTP (vedasi la spiegazione del controllo dello spam e dei virus e delle relative limitazioni). Tutti gli indirizzi mail a destra del ":" vanno necessariamente messi completi di dominio, anche se si riferiscono al dominio locale. Una riga contenente "*:" alla fine del file ridirige qualsiasi indirizzo che non sia stato precedentemente elencato o che non esista come utente (quindi qualsiasi indirizzo "sbagliato") agli utenti indicati a destra del ":". E` possibile anche usare il file degli alias per eseguire delle pipe a script, i quali ricevono la mail in stdin. E` importante ricordarsi che gli script non devono dare output, altrimenti questo output torna come mail al mittente, e che devono avere exit code 0, altrimenti Exim considera la mail come non consegnata. Suggerisco a riguardo di studiare la documentazione di Exim. Nella definizione di un alias che manda a una pipe, si usa il formato "|/path/to/script" come destinatario. Di default lo script viene eseguito con l' utente Debian-exim, gruppo Debian-exim (che e` quello con cui gira Exim). Volendo eseguirlo con un utente diverso, e` possibile definire i parametri aggiuntivi pipe_user e pipe_group, come si puo` vedere nell'esempio (indirizzo "script2").

Per esempio: 

gigi: luigi@pippo.com
info: luigi@pippo.com, ubaldo@pippo.com, clodovalvolo@altrodominio.it:spam_smtp_deny=60
script1: |/opt/applicazione/script1.pl
script2: |/opt/applicazione/script2.pl : pipe_user=utente pipe_group=gruppo
*: poveroutentecheleggetuttalamailconindirizzierrati@pippo.com

Per finire, e` possibile indicare dei domini come "alias" di altri domini. Poniamo che una ditta abbia "pippo.com", "pippo.it" e "pippo.info". dopo aver definito tutti gli utenti e gli alias in "pippo.com", se vuole che gli stessi identici utenti siano raggiungibili anche sugli altri domini che ha, puo` creare un file /etc/vmail/domain_aliases e metterci dentro tante righe ognuna delle quali contiene a sinistra dei ":" il dominio a cui arriva la mail e a destra il dominio (uno solo!) a cui deve essere ridiretta. Anche in questo caso e` possibile indicare come terzo parametro il comportamento che si vuole ottenere dall'antispam.

Per esempio: 

pippo.it:pippo.com
pippo.info:pippo.com:spam_smtp_deny=60

Va notato che in questo caso non e` necessario che esistano files di utenti per i domini "ausiliari" (pippo.it e pippo.info) dentro a /var/vmail/users, tuttavia se esiste un file di utenti per uno di questi domini, all'arrivo di una mail per questo dominio il sistema prima verifichera` se esiste l' utente destinatario della mail nel file degli utenti, e se esiste gli mandera` la mail, poi se non lo trova ridirigera` la mail secondo il file domain_aliases all'utente omonimo in "pippo.com".

Configurazione server smtp autenticato

In questa configurazione esiste anche la possibilita` di accettare sessioni smtp autenticate dagli utenti che magari sono fuori ufficio. Per farlo, ci sono due possibilita`. Il vecchio sistema (disponibile ma obsoleto) consente di autenticare gli utenti SMTP su un file di testo. Il file in questione e` /etc/exim4/passwd.smtp, e va modificato inserendo una riga con username:password per ogni utente che si vuole che usi l'smtp autenticato. (In questo caso probabilmente e` sufficiente inserire una sola coppia di username e password per ogni dominio e poi comunicarla a tutti gli utenti del dominio.)

Il nuovo sistema consente ad Exim di autenticare sul backend di autenticazione usato da Dovecot. In pratica Exim chiede a Dovecot di verficare username e password per l'utente. In questo modo e` sufficiente inserire un utente nella configurazione "standard" (dentro a /etc/vmail/users) per consentirgli anche si usare SMTP autenticato con lo stesso username e password. A riguardo di questo, c'e` un bug in Exim 4.69 (versione di Debian Lenny) per cui exim va in segfault se in Dovecot sono presenti piu` di 6 sistemi di autenticazione diversi. Il report e la patch sono disponibili qui: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551106, e comunque nella configurazione che uso qui il problema non si presenta, almeno spero.

Auto daily alias

In questa configurazione, su suggerimento di Nutella, ho inserito un router di nome "auto_daily_alias" che ha lo scopo di accettare, giorno per giorno, qualsiasi indirizzo di un utente di un dominio locale (niente alias, solo utenti) seguito da un meno (-) e dalla data odierna in formato "ggmmaaaa". Per esempio, il giorno 29/8/2006 se mando una mail a "pippo-29082006@dominio.it" questa mail arrivera` a "pippo@dominio.it". Il giorno dopo, pero`, questo indirizzo non sara` piu` valido. L'idea e` che se dovete iscrivervi a qualche servizio che richiede un indirizzo mail di verifica, e volete pero` che non vi spammino a morte per i prossimi 50 anni, potete fornirgli un indirizzo che e` valido solo fino alla mezzanotte di oggi e poi mai piu`. Questo servizio e` disponibile automaticamente per tutti gli utenti dei domini virtuali.

Autoreply

E` possibile attivare un risponditore automatico in stile "vacation" che risponde alle mail di un utente tramite un messaggio con un subject preimpostato e un testo libero. Per farlo, occorre creare un file con nome /etc/vmail/autoreply/<dominio>/<utente> (ad esempio, /etc/vmail/autoreply/pippo.it/prova per l'utente "prova@pippo.it"). All'interno di quel file, va scritto il testo della risposta automatica, che puo` essere lungo quanto si vuole e composto di piu` righe senza problemi. L'autoreply e` limitato a una risposta al giorno per mittente, questo limite e` impostabile solo nella configurazione ed e` valido per tutti gli utenti, non si puo` differenziare per singolo utente. Per disattivare l'autoreply, va cancellato o rinominato il file.

Black e white lists

E` possibile creare una white list di hosts remoti dai quali si accetta sempre la mail, questa e` composta da un file con un host per riga. Il file si chiama /etc/exim4/white.list (a meno che non venga modificato il suo nome in exim4.conf) e in sua assenza la funzione e` disattivata. Allo stesso modo e` possibile creare una black list di host dai quali non accettiamo MAI la mail, in NESSUN CASO. Il file si chiama /etc/exim4/black.list.

E` possibile inoltre creare una lista di indirizzi locali (destinatari delle mail) ai quali la mail viene recapitata comunque, saltando tutti i controlli sulle RBL e sullo spam (ma non sui virus). Questi indirizzi vanno indicati, uno per riga, nel file /etc/vmail/allowed_recipients.

Configurazione filtri per gli utenti dei virtuali

E` possibile impostare dei filtri per gli utenti dei domini virtuali, nella forma di "forward files" o di filtri (Exim filter o Sieve Filter) creando un file per ogni utente, con nome /etc/vmail/filters/<dominio.tld>/<utente>. Questi files, che e` opportuno per motivi di sicurezza che NON siano creabili dagli utenti stessi ma solo dal sysadmin, possono servire per qualsiasi cosa si possa fare con un filtro di Exim. Per come e` fatto ora il sistema, eventuali delivery su file system (file, directory o anche pipe) sono fatti dall'utente "mail" gruppo "mail", per consistenza con il delivery che viene fatto normalmente dagli utenti dei domini virtuali. (al momento ho testato solo il delivery su directory).

Il motivo principale per cui ho creato questi filtri e` quello di suddividere direttamente in vari folder i messaggi in base a regole, per esempio per smistare i messaggi in vari folder IMAP a seconda della mailing list a cui appartengono.

Volendo, sono disponibili una serie di variabili da usare nei filtri. Quelle "personalizzate" di questa configurazione sono:

Un esempio di filtro per dividere i messaggi in folders e` questo: (ovviamente vanno messi a posto i path con i dati giusti al posto di <domain> e <user>) 

# Exim filter

# Questo e` sempre bene metterlo per evitare loops in caso di errori.
if error_message then finish endif

# Check se il list_id e` "xxx" allora scrivi nel folder della lista "xxx"
if $header_List-id: contains "xxx xxx xxx"
then
        save /var/vmail/<domain>/<user>/.Lista_XXX/
endif

# Qui si possono mettere altri check per altre liste

Tweaks generali del sistema

Se usate findutils (locate e updatedb) e` il caso di configurare updatedb in modo da ignorare le directory contenenti le maildir per non affogarlo in migliaia di files inutili. Vedasi il file /etc/updatedb.conf.

Statistiche

Nutella mi passa questo suggerimento per le statistiche: 

exigrep -l "virtualdomain.com" /var/log/exim/exim_mainlog | eximstats -options-of-your-choice > reportfile

Per fare statistiche sullo spam fermato dai vari sistemi (spamassassin, RBL, eccetera) si possono usare comandi del tipo: 

exigrep -l "sorbs" /var/log/exim4/mainlog.*  | wc

Mettendo il dominio della lista (per esempio "sorbs", o "spamhaus") per identificare i messaggi bloccati dalle varie RBL; il risultato va diviso per 2. Per i messaggi bloccati dal spamassassin su puo` usare la stringa "spam score too high"; in questo caso il risultato va diviso per 3. Per i messaggi contenenti virus si puo` usare la stringa "This message contains a virus"; il risultato va diviso per 2.

Pulizia delle maildir

Per tenere piu` o meno pulite le mie maildir, uso degli script banali messi in cron: il primo ha lo scopo di cancellare (solo da un account specifico) tutte le mail piu` vecchie di 180 giorni, e usa archivemail per farlo. Tra l'altro, archivemail puo` anche essere usato per archiviare (e non cancellare e basta, che e` come dire archiviare nel gufo) le mail. Questa che segue e` una riga in /etc/crontab 

# pulizia delle mailbox dell'account bofh, la roba viene cancellata dopo 180 giorni
30 03 * * 7     mail     archivemail --delete /var/vmail/kurgan.org/bofh/.*

Il secondo script cancella le mail marcate come "cancellate" dal client IMAP. Attenzione: non sono sicuro che funzioni sempre e non sono sicuro che non cancelli roba che non deve cancellare, perche` non so se la regexp sia perfetta oppure ogni tanto si perda qualcosa, o peggio includa qualcosa che non deve. Suggerisco di usare (in dovecot 2.x) il comando doveadm che ha una funzione apposta. Devo ancora studiarlo a fondo, pero`. 

# pulizia delle mail marcate per la cancellazione
40 03 * * 7     mail     find /var/vmail/ -regex  ".*:.*,.*T.*[a-z]$" -type f -exec rm  \{} \;

Un altro script puo` essere utile se si vuole cancellare automaticamente la roba dalla directory imap ".Spam", supponendo che gli utenti abbiano la configurazione che riceve lo spam e lo salva in quella directory. 

# Eliminazione dello spam dopo 15 giorni
30 22 * * *     mail    find /var/vmail/ -type d -name .Spam -exec archivemail --delete --quiet -d 15 \{} \;

Configurazione di Exim per uno smarthost

Se si vuole che Exim mandi la mail tramite uno smarthost e non direttamente, occorre andare nella sezione "routers" del file exim.conf, commentare tutto il primo router in alto, chiamato "dnslookup" e sostituirlo con questo qui sotto. In questo esempio lo smarthost e` "smtp.libero.it", ovviamente occorre mettere lo smarthost che si vuole usare. 

smarthost:
   driver = manualroute
   domains = ! +local_domains : ! $primary_hostname : ! localhost : ! lsearch;VIRTUALS/domain_aliases
   transport = remote_smtp
   route_list = * smtp.pappappero.it
   no_more

Se si vuole mandare mail via smarthost solo per alcuni domini, e` possibile farlo inserendo due router in sequenza: lo smarthost prima e poi il dnslookup. La parte del dnslookup non e` modificata rispetto a quella che trovate nel file di configurazione "standard" allegato a questa pagina del wiki. Questo e` un esempio per mandare la mail a tiscali (ed altri due domini, separati da ":") attraverso lo smarthost "smtp.pappappero.it" e al resto del mondo direttamente: 

smarthost:
   driver = manualroute
   domains = tiscali.it : secondodominio.it : terzodominio.com
   transport = remote_smtp
   route_list = * smtp.pappappero.it
   no_more

dnslookup:
  driver = dnslookup
  domains = ! +local_domains : ! $primary_hostname : ! localhost : ! lsearch;VIRTUALS/domain_aliases
  transport = remote_smtp
  ignore_target_hosts = 0.0.0.0 : 127.0.0.0/8
  no_more

Configurazione per uno smarthost autenticato

Per mandare mail tramite uno smarthost autenticato la procedura e` allucinantemente complessa. Occorre modificare diverse configurazioni:

Prima di tutto occorre indovinare quali autenticatori piacciono al remoto. Si puo` chiederlo con uno "ehlo xxx" al remoto e vedere che sistemi di auth gradisce. Dopo averlo scoperto, occorre modificare un autenticatore fra quelli locali in modo da includere una configurazione "client", in quanto nella config che uso gli autenticatori sono configurati solo come "server". A seconda di quali autenticatori vogliamo modificare, cambia la sintassi da usare, giusto per rendere le cose piu` facili.

Veniamo al dunque: prendendo come esempio quello precedente (smtp.pappappero.it) dovremo:

Nota bene: ho avuto in alcuni casi problemi di "conflitto" degli autenticatori client con quelli server (ovvero, quelli "dovecot_qualcosa" presenti nella configurazione di default) in quanto Exim si lamentava che il "public name" dei due autenticatori (quello server e quello client) era il medesimo. Con Exim versione 4.72 il problema apparentemente non si presenta. Non ho idea esattamente di cosa sia cambiato, o se sia io che sono rincoglionito.

Conversione mailbox in maildir

Se dovesse servire convertire delle mailbox da un vecchio server in maildir, si puo` fare con mb2md. Prima di tutto installare il pacchetto mb2md e quindi convertirle con la sintassi: 

mb2md  -s /file/della/mailbox -d /var/vmail/dominio/utente

Attenzione: la destinazione deve essere per forza un path completo, e lo script va eseguito da utente mail altrimenti i files generati nelle maildir sono di root e poi mail (ovvero dovecot) non puo` piu` modificarli.

BUGS