Diff for "LinuxDebian/Exim4-Dovecot-OLD"

Mail server con Exim4 / Dovecot / Clamav / Spamassassin

Nuovo: Aggiornato con le differenze fra Sarge e Etch.

Nuovo: La configurazione per Etch sembra funzionare anche per la RC1 di Lenny.

Attenzione: il file di configurazione di exim per etch contiene modifiche che in sarge non ci sono. Di fatto la versione per sarge non e` piu` supportata

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.

• Prima di tutto vengono controllare le varie RBL, viene verificato che il mittente esista (nota: in una piu` recente versione della configurazione di Exim ho dissttivato questo controllo in quanto sembra dare piu` problemi che vantaggi, comunque e` sempre possibile riattivarlo) e quando e` possibile viene verificato che anche il destinatario esista. Questi controlli vengono saltati in toto (e la mail accettata) se l'host mittente e` in whitelist, se la mail e` inviata da un host della mia LAN o a mezzo di SMTP autenticato, e se il destinatario della mail e` in un elenco di destinatari che per definizione accettano qualsiasi porcheria (VIRTUALS/allowed_recipients).

• Poi viene fatto il check antivirus, il quale viene fatto sempre a meno che il destinatario della mail non sia un utente che ha impostato nella sua configurazione che non vuole il controllo antivirus. Questa feature (la disabilitazione del controllo antivirus) l'ho messa perche` potrebbe servire in casi molto particolari, ma consiglio vivamente di non usarla e lasciare che il controllo antivirus avvenga sempre. Se il destinatario e` un alias o un domain_alias il controllo AV viene sempre fatto.

• Poi viene fatto il check antispam, a meno che l'host mittente non sia in whitelist, la mail non sia inviata da un host della mia LAN o a mezzo di SMTP autenticato, o il destinatario della mail non sia in un elenco di destinatari che per definizione accettano qualsiasi porcheria.
• Se il punteggio dell'antispam supera una soglia definita a livello di sistema, la mail viene rifiutata durante la sessione SMTP.
• Se il destinatario della mail ha impostato una soglia per il rifiuto dello spam a livello SMTP, e il messaggio la supera, viene rifiutato a livello SMTP. Attenzione, perche` se il destinatario e` un utente vale la soglia impostata per l'utente, se e` un alias vale la soglia impostata per l'alias, se e` un domain_alias vale la soglia per l'intero dominio impostata appunto nel file domain_aliases. Se ci sono diversi destinatari, conta l'impostazione del primo della lista. Questo sistema e` tutt'altro che perfetto, ma non si puo` fare diveramente a questo livello.

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:

• Accettarlo comunque (nel messaggio ci sono degli header che possono essere usati per decidere cosa fare a livello di MUA)
• Marcarlo come spam nel subject in caso superi una certa soglia di spammosita` (utile per i MUA stupidi come Outlook Express)
• Buttarlo via completamente nel caso superi una certa soglia di spammosita`
• Gestire lo spam nei filtri utente (se ha il diritto di usarli) come meglio crede, usando le variabili impostate da spamassassin.

Pacchetti

I pacchetti usati sono:

• dovecot-imapd dovecot-pop3d (versione 1.0rc presa da backports.org per Sarge; quello ufficiale per Etch)
• exim4-daemon-heavy
• clamav-daemon
• spamassassin
• razor

Per avere delle versioni aggiornate di clamav (e di spamassassin) e` opportuno usare volatile.debian.net come repository, aggiungendo a /etc/apt/sources.list la riga:

deb http://volatile.debian.net/debian-volatile etch/volatile main contrib non-free

Per installare Dovecot da backports (SOLO SARGE!) la soluzione semplice e`:

• Aggiungere backports a /etc/apt/sources.list:

  deb http://www.backports.org/debian sarge-backports main contrib non-free

• Eseguire un update e poi installare i pacchetti necessari forzando l'uso di backports. I pacchetti di Backports hanno priorita` bassa quindi non si installeranno mai al posto di quelli ufficiali a meno che non li si forzi. Installando i pacchetti di backports si installano ovviamente anche le dipendenze da backports, quindi attenzione che queste non creino problemi. Nel caso, dovrete compilarvi dovecot dai sorgenti, perche` quello in Sarge e` proprio vecchio.

  apt-get update
  apt-get -t sarge-backports install dovecot-imapd dovecot-pop3d

Nota: e` necessario durante l'installazione rispondere ad alcune delle domande poste dal setup di exim4-config, anche se queste risposte sono totalmente inutili perche` la configurazione Debian di Exim4 sara` rasa al suolo senza pieta`.

Configurazione di Dovecot

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 nuove chiavi, perche' quelle fornite con il pacchetto Debian di Dovecot sono scadute. Le chiavi possono essere generate autonomamente tramite easy-rsa oppure firmate da una vera CA "ufficiale", fondamentalmente dipende se volete spendere dei soldi oppure no. Le chiavi devono essere messe (per default) dentro /etc/ssl/certs/ ed /etc/ssl/private/ con il nome "dovecot.pem". Il certificato ovviamente e` in "certs" e la chiave privata in "private". Volendo e` possibile spostare le chiavi da qualche altra parte, fate riferimento alla documentazione di dovecot. Con le chiavi auto-generate, se si usa The Bat come client, occorre "insegnare" a The Bat che la CA che ci siamo fatti in casa e` valida, per farlo occorre aggiungere il certificato della CA alla rubrica delle "Trusted CA". Con Thunderbird e` sufficiente dirgli, la prima volta che ci si collega, di accttare il certificato del server come valido per sempre.

Se is 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.

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


# SOLO PER ETCH (almeno credo)
# 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

# 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_extra_groups = mail (per le vecchie versioni usare questo)
mail_privileged_group = mail


##
## IMAP specific settings
##

protocol imap {
  imap_client_workarounds = outlook-idle
}

##
## 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 digest-md5 cram-md5 apop ntlm rpa
  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 = /etc/vmail/users/%d
 }
}

Configurazione di Exim

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

• Creare la directory /var/vmail che conterra` la mail degli utenti dei domini virtuali e poi darle permessi 770 e assegnarla all'utente mail gruppo mail.

  mkdir /var/vmail
  chown mail.mail /var/vmail
  chmod 770 /var/vmail

• Creare la directory /etc/vmail e le sottodirectory che conterranno tutte le configurazioni dei domini virtuali. Creare il file /etc/vmail/domain_aliases, vuoto, per evitare di avere errori. Questo file potra` poi essere usato o meno, a seconda delle necessita`. Il suo uso e` spiegato piu` avanti.

  mkdir /etc/vmail
  mkdir /etc/vmail/users
  mkdir /etc/vmail/aliases
  mkdir /etc/vmail/filters
  mkdir /etc/vmail/autoreply
  touch /etc/vmail/domain_aliases

• Tutti i files dentro /etc/vmail dovranno essere leggibili (e non scrivibili) dal gruppo "Debian-exim" (con la maiuscola!) che e` il gruppo con cui di default gira Exim4 in Debian. I files che contengono le password devono essere NON LEGGIBILI da tutti.

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 Sarge: exim4.conf e qui per Etch: exim4.conf.etch

NOTE:

• In Sarge, la scansione antivirus la faccio dentro alla acl "acl_smtp_data" usando la funzione "demime" che e` deprecata. Dovrebbe essere fatta dentro l'acl "acl_smtp_mime", ma la versione 4.50 di Exim che c'e` in Sarge e` bacata e la soluzione che uso e` quella che di fatto funziona meglio. Usando versioni piu` nuove di Exim, il check dei virus va modificato (questa modifica c'e` gia` nel config per Etch).
• Le scansioni antivirus e antispam NON vengono fatte per gli utenti veri (quelli in /etc/passwd) della macchina. L'idea e` che questo sistema nasce per servire la mail solo agli utenti virtuali.
• Il meccanismo di insegnamento al filtro bayesiano NON e` stato minimamente provato

• per fare test, sono comodi i comandi "exim4 -bs -d" (sessione smtp con debug violento a console) ed "exim4 -e 'expressione'" per testare l'espressione (espansioni di variabili, if, e quant'altro). E` utile anche "exim4 -bh <indirizzo ip>.<porta> -d" che finge una sessione smtp provienente dall'indirizzo ip e porta indicati.

Configurazione di Spamassassin

• Editare il file /etc/defaul/spamassassin ed impostare ENABLED=1

• Se si vuole usare spamd attraverso un socket e non attraverso una connessione tcp a localhost, e` possibile farlo modificando /etc/default/spamassassin in modo da aggiungere alle opzioni quella per usare il socket (socketpath=xxx). In questo modo la riga OPTIONS diventa:

  OPTIONS="--create-prefs --max-children 5 --helper-home-dir --socketpath=/var/run/spamd.ctl"

  Questa configurazione e` piu` sicura in quanto non usa il tcp ma solo un socket locale, pero` ovviamente impedisce di usare exim su una macchina e spamassassin su un'altra (o su un pool di altre macchine, opzione valida per fare load balancing). E` importante ricordare che se si usa il socket occorre dirlo anche ad Exim, modificando exim.conf. La configurazione qui allegata usa il socket.

• E` opportuno modificare il file /etc/spamassassin/local.cf per disattivare il check delle RBL da parte di spamassassin, in quanto il check e` gia` fatto da Exim prima di passare le mail a spamassassin. Inoltre e` possibile nello stesso file modificare i punteggi dati ai vari filtri. Il mio attuale e` modificato per aumentare il punteggio di Razor e diminuire quello di Habeas, il quale viene puntualmente abusato. Anche la configurazione del report, che viene incluso poi da Exim come header nelle mail, e` stata modificata in modo da averne uno piu` "stringato" rispetto all'originale.

  # disattivazione check RBL
  skip_rbl_checks 1
  
  # Report personalizzato (MOLTO piu` ridotto dell'originale)
  clear_report_template
  report _TESTSSCORES_ (_SCORE_ points, _REQD_ required)
  
  # modifiche dei punteggi
  score   HABEAS_SWE              0.1
  score   RAZOR2_CF_RANGE_51_100  3.0

• Eseguire /etc/init.d/spamassassin start per avviare il demone spamd (ovviamente al reboot partira` da solo)

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:

# SOLO IN ETCH, in sarge non funziona e fa casino!
logfile = sys-syslog

logic_method = 4
ignorelist = 1
report_headers = 0

• Configurare Razor per la prima volta, come utente "mail", visto che poi girera` sempre come utente "mail".

# su - mail
$ 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/groups, altrimenti clamd non puo` accedere ai files che exim gli passa da scansionare. Dopo aver fatto questa modifica riavviare clamd. Occorre anche verificare che nel file /etc/clamav/clamd.conf vi sia la direttiva "AllowSupplementaryGroups yes" altrimenti clamd ignora i gruppi ai quali l'abbiamo appena aggiunto (le vecchie versioni non l'avevano di default, quelle nuove si`).

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:

• virus "virus=off" disattiva il check antivirus, qualsiasi altro valore o l'assenza della variabile lo attiva

• smap_smtp_deny indica la soglia alla quale il messaggio deve essere rifiutato a livello smtp. Occorre ricordare che questa soglia e` uguale al punteggio di spamassassin moltiplicato per 10 (quindi il classico "5" di default vale 50)

• spam_blackhole indica la soglia alla quale il messaggio viene buttato via senza segnalare nulla al mittente ne` al destinatario. Anche qui come sopra la soglia va moltiplicata per 10.

• spam_subject indica la soglia alla quale il subject va modificato per inserirvi una indicazione del fatto che la mail e` considerata spam. Anche qui come sopra la soglia va moltiplicata per 10.

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:virus=off

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 ":".

Per esempio:

gigi: luigi@pippo.com
info: luigi@pippo.com, ubaldo@pippo.com, clodovalvolo@altrodominio.it:spam_smtp_deny=60
*: 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, occorre editare il file /etc/exim4/passwd.smtp inserendo una riga con username:password per ogni utente che si vuole che usi l'smtp autenticato. Di solito e` sufficiente inserire una sola per dominio e poi comunicarla a tutti gli utenti del dominio. Sto cercando di usare gli stessi username e password del pop3/imap4, ma ci vorra` della calma per arrivarci in fondo.

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

TODO: indicare quali variabili per controllo spam

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.

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 (in Debian Sarge) /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 due 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. LE mail marcate come "cancellate" hanno un flag "T" in fondo al nome del file. (letteralmente, il nome del file finisce con "T"). Anche questo e` messo in cron. Occhio, se cancellate tutto non e` colpa mia!!!

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

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.libero.it
   no_more

BUGS

Questi sono bugs che so che esistono ma che non ho ancora avuto tempo/voglia di sistemare.

• BUG RISOLTO, almeno spero: I due routers "virtual_spam_owl" e "virtual_spam_add_subject" non fanno un check dell'esistenza del file VIRTUALS/users/<domain> prima di farci un lsearch sopra, quindi vanno in errore di brutto se per caso questo file manca per un dominio che pero` esiste. Il caso evidente e` se si ha un dominio aliasato in VIRTUALS/domain_aliases che pero` non ha utenti locali. In questo caso e` necessario creare un file di utenti per il dominio, lasciandolo vuoto.

• Apparentemente Outlook (e altri programmi M$) fanno casino con l'autenticazione NTLM (o SPA). In pratica pare che il client si ingrippi in mezzo alla negoziazione, e anziche` rispondere al server con la stringa giusta, inizi a mandare via la mail "saltando un pezzo" della procedura di autenticazione. Se l'autenticazione NTLM/SPA non vi funziona, disabilitatela in Exim. Io al momento non ho trovato altre soluzioni. Chiaramente la cosa fa particolarmente ridere perche` l'autenticazione NTLM l'ha inventata M$, ed e` l'unica "non-plaintext" supportata da Outlook.
• Pare che Dovecot, quando autentica su file di testo, si incasini se nello username c'e` un underscore, e in questo caso non riconosca piu` la password (anzi, attenzione, che accetta una password VUOTA!). Occorre indagare nei sorgenti di Dovecot, quando ne avro` voglia... cioe` mai. Apparentemente questo comportamento non e` sempre vero. In alcuni casi l'ho visto funzionare bene. Non sono sicuro che questo bug ci sia davvero o che dipenda da qualche casino esterno (file di config corrotti?)

• BUG RISOLTO, almeno spero: Devo modificare la configurazione separando la lista "+local_domains" in due parti, una per i domini veramente locali (la macchina stessa, o localhost) e uno per i virtuali, avendo cura di correggere dappertutto nella config dove occorre che appaiano tutti e due i "tipi" di domini, e dove solo l'uno o solo l'altro. Mi sono accorto di questo problema perche` ci sono errori nel panicolog se qualcuno cerca di mandarmi una mail a "tizio@localhost" o simili cazzate. Non crea problemi, ma fa` errori che finiscono nel paniclog ed e` fastidioso.