Se avete il mail server in proprio potrebbe succedere che questo non sia raggiungibile dall'esterno; ad esempio una mancanza di corrente, un problema alla connessione di rete ecc..

In questo caso succede che tutte le mail dirette al vostro server non verranno consegnate, peggio ancora, se l'interruzione è prolungata può succedere che queste vengano ritornate al mittente per l'impossibilita di consegnarvele!

Ecco allora che si rende necessario avere un mail server di backup in modo tale che quando il server primario non funziona il secondario possa ricevere le mail in sua vece, e poi, una volta che il primario ritorna attivo, il secondario rimandi tutte le mail ricevute al server primario.

Proprio in questi giorni mi  è successo che il mio caro mail server fosse fuori uso a causa di un problema di connessione alla rete. Io ho la gestione della posta interna su un mio server dedicato perché mi permette di avere una versatilità di gestione della posta che non avrei utilizzando un server classico di posta.

Questa soluzione però, come già osservato, si rivela fallace quando il mail server non è raggiungibile dall'esterno. Se poi la disconnessione è prolungata il problema si ingrandisce perché non sono in grado di ricevere alcunché per molto tempo e rischio di perdere delle mail importanti!

Come fare?

Beh, innanzi tutto dovrei avere un'altra macchina connessa direttamente alla rete che possa funzionare da mail server di backup, ma non solo dovrei anche fare in modo che questa riceva le lettere e le costudisca fino a che il mio mail server primario non riparte.

Ecco come ho risolto.

Nel mio caso il mail server primario è mail.enneenne.com mentre il mail server secondario, che andrò a configurare come mail server di backup, è mail.consulenti-ict.it (ebbene sì, uso il mail server del portale ;).

Una soluzione molto veloce ma semplicistica potrebbe essere quella di configuarare il secondario in modo tale che questo faccia il relay della posta diretta al primario, cioè ad enneenne.com, ma questa soluzione presenta alcuni inconvenienti:

1. Gli indirizzi di posta @enneenne.com non sono controllati sul secondario ed è quindi possibile per gli spammer generare messaggi di spam che sfruttano questa mancanza.
2. Quando il primario è disconnesso dalla rete non mi è possibile vedere la posta che mi arriva, questa infatti rimane nella coda del server secondario e finché non raggiunge il primario non la posso leggere con il mio client di posta preferito  (che, per la cronaca è mutt). Questo non è un vero e proprio problema per le piccole interruzioni, ma per le lunghe sì, perché mi impedisce di leggere la posta per lunghi periodi.

E' per questo che ho deciso di adottare una soluzione un po' diversa e che risolve entrambi i problemi a patto però di lavorare e complicare la soluzione un pochino di più.

La mia soluzione

La mia soluzione prevede di configurare il server secondario come un mail server di ricezione della posta e non di semplice relay, in questo modo duplicando la configurazione del server primario posso decidere quali indirizzi di posta sono definiti nel sistema bloccando, di fatto, l'attività dei nostri «amici» spammer.

Su mail.consulenti-ict.it ho semplicemente aggiunto un dominio virtuale nel file /etc/aliases.virtual/enneenne.com come segue:

# cat /etc/aliases.virtual/enneenne.com
rodolfo.giometti: giometti
r.giometti: giometti
giometti: giometti@localhost

in questo modo faccio sì che il server secondario riceva la mia posta, e solo la mia, sul dominio enneenne.com (è ovvio che poi dovrò riportare anche tutti gli altri indirizzi notevoli definiti sul primario altrimenti alcuni indirizzi di posta possono essere rifiutati se si tenta di inviarli al secondario).

Poi devo dire al mail server (exim4 su Debian nel mio caso) di accettare anche la mail per il dominio enneenne.com (e enneenne.it); uso il comando:

# dpkg-reconfigure exim4-config

e poi rispondo alle domande dello script di configurazione in modo che il file /etc/exim4/update-exim4.conf.conf contenga:

# grep enneenne /etc/exim4/update-exim4.conf.conf
dc_other_hostnames='consulenti-ict.it:ml.consulenti-ict.it:professionisti-ict.it:ml.professionisti-ict.it:enneenne.com:enneenne.it'
dc_relay_domains='ml.enneenne.com:ml.enneenne.it'

(si noti che così facendo i domini ml.enneenne.con e ml.enneenne.it non sono gestiti in questa modalità ma con il relay).

Allo script dico anche che la posta locale deve essere consegnata nella home di ogni singolo utente in formato Maildir.

Bene, così facendo la posta che non raggiunge il primario raggiunge il secondario e viene depositata nella mia home.

Ma come faccio a leggerla e poi a ritrasferirla sul primario? La risposta è semplice: uso IMAP+FETCHMAIL.

Il protocollo IMAP permette di leggere la posta da un client locale ma che risiede su di un server remoto, mentre FETCHMAIL è un programma che, grazie ad IMAP (ma anche ad altri protocolli similari), mi permette di scaricare la posta da un server remoto e di memorizzarla in locale come se la ricevessi sul primario. Ma non solo, nel mio caso uso PROCMAIL per smistare la posta in entrata e FETCHMAIL mi permette di usarlo in maniera del tutto trasparente se lanciato con i parametrio opportuni (ma andiamo con ordine).

Il server IMAP

Prima di tutto installo il server IMAP su mail.consulenti-ict.it:

# aptitude install courier-imap-ssl

Installo la versione su SSL perché più sicura. Una volta finito il sistema mi genera un certificato di default, ma io ne voglio uno ad hoc, per cui lo rifaccio. Prima cancello quelli di default:

# rm /etc/courier/imapd.pem
# rm /usr/lib/courier/imapd.pem

Poi metto i miei parametri nel file /etc/courier/imapd.cnf come segue:

[ req ]
default_bits = 1024
encrypt_key = yes
distinguished_name = req_dn
x509_extensions = cert_type
prompt = no

[ req_dn ]
C=IT
ST=IT
L=Lucca
O=Courier Mail Server
OU=consulenti-ict.it IMAP SSL key
CN=mail.consulenti-ict.it
emailAddress= Questo indirizzo e-mail è protetto dallo spam bot. Abilita Javascript per vederlo.

Quindi lancio lo script per rigenerare un certificato:

# /usr/lib/courier/mkimapdcert

Una volta finilo lo salvo dove il demone IMAP lo leggerà:

# mv /usr/lib/courier/imapd.pem /etc/courier/imapd.pem

Ok, ora devo aggiustare il file di configurazione del demone non SSL in modo che non parta: basta mettere a NO la variabile IMAPDSTART nel file /etc/courier/imapd.

Poi nel file di configurazione del demone SSL (file /etc/courier/imapd-ssl) devo solo verificare che la variabile IMAPDSSLSTART sia impostata a YES e che MAILDIRPATH valga Maildir. A questo punto faccio ripartire il tutto:

# /etc/init.d/courier-imap restart
Stopping Courier IMAP server: imapd.
# /etc/init.d/courier-imap-ssl restart
Stopping Courier IMAP-SSL server: imapd-ssl.
Starting Courier IMAP-SSL server: imapd-ssl.

Ora per verificare che il server funzioni posso testarlo con il tool openssl che mi permette di aprire una connessione SSL semplice:

$ openssl s_client -connect mail.consulenti-ict.it:993
CONNECTED(00000003)
depth=0 /C=IT/ST=IT/L=Lucca/O=Courier Mail Server/OU=consulenti-ict.it IMAP SSL key/CN=mail.consulenti-ict.it/emailAddress= Questo indirizzo e-mail è protetto dallo spam bot. Abilita Javascript per vederlo.
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=IT/ST=IT/L=Lucca/O=Courier Mail Server/OU=consulenti-ict.it IMAP SSL key/CN=mail.consulenti-ict.it/emailAddress= Questo indirizzo e-mail è protetto dallo spam bot. Abilita Javascript per vederlo.
verify return:1
...
* OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE AUTH=PLAIN ACL ACL2=UNION] Courier-IMAP ready. Copyright 1998-2008 Double Precision, Inc.  See COPYING for distribution information.

Direi che ci siamo! Per testare la connesisone IMAP creo un utente ad hoc, gli mando una mail di prova e poi provo a leggerla. Con adduser ho aggiunto l'utente test (con password xxxxx) e con il comando mail gli ho mandato una mail di prova; a questo punto posso fare:

. login test xxxxx
. OK LOGIN Ok.

Sì, il server va benone.

Bene, a questo punto potrei già leggere la posta utilizzando il mio client di posta preferito, che, vi ricordo, è mutt. Basta infatti che dia il comando:

$ mutt -f 'imaps:// Questo indirizzo e-mail è protetto dallo spam bot. Abilita Javascript per vederlo. :993/INBOX'

Ovviamente così non leggo la mia posta ma qualla dell'utente test, ma basta cambiare opportunamente il comando e potrò leggere la mia posta sul server di backup!

A questo punto il il server secondario è pronto e quindi per comunicare al mondo che la posta può essere inviata lì, quando il primario non va, basta modificare il DNS del dominio enneenne.com (ed enneenne.it) in modo tale da aggiungere un campo MX a bassa priorità. Nel mio caso ho messo:

$ dig enneenne.com MX

; <<>> DiG 9.2.4 <<>> enneenne.com MX
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56780
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 3

;; QUESTION SECTION:
;enneenne.com.            IN    MX

;; ANSWER SECTION:
enneenne.com.        900    IN    MX    40 mail.consulenti-ict.it.
enneenne.com.        900    IN    MX    10 mail.enneenne.com.

A questo punto posso verificare che dopo un po' di tempo, se il primario è sempre giù, la posta arriva sul secondario.

Rimandare la posta sul server primario

A questo punto manca solo il modo di rimandare la posta ricevuta dal secondario sul server di posta primario: usiamo FETCHMAL.

Questa è un'operazione molto semplice perché dal primario basta dare il comando:

$ fetchmail --user test --proto imap --ssl --mda "procmail -f %F" --all --keep mail.consulenti-ict.it

Questo comando scarica tutte le mail dell'utente test sia che sia state già marcate come viste (seen) o meno grazie all'opzione --all (questo e utile se decido di leggerle prima tramite mutt), inoltre grazie all'opzione --keep le mail non vengono cancellate una volta scaricate: risulta utilissimo quindi per fare i test di ricezione della posta.

Una volta che tutto va bene posso rilanciarlo senza e la posta verra spostata dal primario al secondario e cancellata.

E' chiaro che questa soluzione obbliga tutti gli utenti che ricevono posta su enneenne.com (e it) a lanciare quello script, ma questo non è un problema perché basta fare uno script ed eseguirlo regolarmente con una crontab ad hoc per risolvere il problema. ;)